Incorrectly processing the filename from the content-disposition header #301

Open
opened 2026-02-28 04:37:40 -05:00 by deekerman · 0 comments
Owner

Originally created by @heymoe on GitHub (Feb 13, 2026).

Originally assigned to: @dnzbk on GitHub.

Is there already an issue for your problem?

  • I have checked older issues, open and closed

NZBGet Version

v26.0-stable

Platform

Linux/Docker

Environment

OS: Alpine Linux 3.22.3 (Running in Docker)
CPU: KVM64
Arch: x86_64
Docker Image: lscr.io/linuxserver/nzbget:latest

Current Behavior

NZB files downloaded from a Spottarr instance gets named incorrectly in NZBGet's queue. It seems that most sources of NZB files set their content-disposition to something like:

content-disposition: attachment; filename="My Filename.nzb"

Which gets added to NZBGet's queue as: "My Filename"

Spottarr seems to be adding a UTF-8 encoded filename along with a compatibility filename in its context-disposition header like so:

content-disposition: attachment; filename=1313961.nzb; filename*=UTF-8''1313961.nzb

Which gets added to NZBGet's queue as: "1313961.nzb; filename*=UTF-8''1313961"

This was originally reported in Spottarr's repo (https://github.com/Spottarr/Spottarr/issues/123) but it looks like the OG reporter didn't follow up over here.

Expected Behavior

Correctly parse the filename from the context-disposition when multiple filenames / UTF-8 filename is provided. So if the content-disposition is:

content-disposition: attachment; filename=1313961.nzb; filename*=UTF-8''1313961.nzb

NZBGet would add it as: "1313961" to its queue.

Steps To Reproduce

  1. Get an Spottarr NZB download URL (example: https://spottarr.site.com/newznab/api?t=get&guid=1)
  2. Click add in NZBGet
  3. Paste the Spottarr URL into the "Add from URL" field.
  4. Click Submit

NZBGet will fetch the NZB file via the URL and it will get added as : 1 nzb; filename =UTF-8''1

Logs

None at this time

Extra information

No response

Originally created by @heymoe on GitHub (Feb 13, 2026). Originally assigned to: @dnzbk on GitHub. ### Is there already an issue for your problem? - [x] I have checked older issues, open and closed ### NZBGet Version v26.0-stable ### Platform Linux/Docker ### Environment ```markdown OS: Alpine Linux 3.22.3 (Running in Docker) CPU: KVM64 Arch: x86_64 Docker Image: lscr.io/linuxserver/nzbget:latest ``` ### Current Behavior NZB files downloaded from a Spottarr instance gets named incorrectly in NZBGet's queue. It seems that most sources of NZB files set their content-disposition to something like: `content-disposition: attachment; filename="My Filename.nzb"` Which gets added to NZBGet's queue as: "My Filename" Spottarr seems to be adding a UTF-8 encoded filename along with a compatibility filename in its context-disposition header like so: `content-disposition: attachment; filename=1313961.nzb; filename*=UTF-8''1313961.nzb` Which gets added to NZBGet's queue as: "1313961.nzb; filename*=UTF-8''1313961" This was originally reported in Spottarr's repo (https://github.com/Spottarr/Spottarr/issues/123) but it looks like the OG reporter didn't follow up over here. ### Expected Behavior Correctly parse the filename from the context-disposition when multiple filenames / UTF-8 filename is provided. So if the content-disposition is: `content-disposition: attachment; filename=1313961.nzb; filename*=UTF-8''1313961.nzb` NZBGet would add it as: "1313961" to its queue. ### Steps To Reproduce 1) Get an Spottarr NZB download URL (example: https://spottarr.site.com/newznab/api?t=get&guid=1) 2) Click add in NZBGet 3) Paste the Spottarr URL into the "Add from URL" field. 4) Click Submit NZBGet will fetch the NZB file via the URL and it will get added as : 1 nzb; filename =UTF-8''1 ### Logs None at this time ### Extra information _No response_
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/nzbget#301
No description provided.