starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Enhancement]: Support compressed content in podcast feed downloads #2518

New Issue
Closed
opened 2026-04-25 00:07:58 +02:00 by adam · 1 comment
adam commented 2026-04-25 00:07:58 +02:00
Owner
Copy Link
Copy Source

Originally created by @Vynce on GitHub (Jan 23, 2025).

Please consider adding an Accept-Encoding: deflate, gzip request header to podcast feed downloads and handle the resulting compressed responses.

Context

Audiobookshelf 2.18.1 started to fail fetching one of my podcast member feeds. Something changed in their backend and now only requests that include an Accept-Encoding header work. I'm working with their support to see if they can track down the issue on their end, but it still seems worthwhile for Audiobookshelf to support compressed http transactions to reduce bandwidth usage.

Looking at the Audiobookshelf logs, there's currently no Accept-Encoding header in the feed requests:

headers: {
      Accept: 'application/rss+xml, application/xhtml+xml, application/xml, */*;q=0.8',
      'User-Agent': 'audiobookshelf (+https://audiobookshelf.org; like iTMS)'
    },

Examples

❌ Reproducing the issue with curl, here's an example of it failing without compression. To be clear, this is an issue on the server end and shouldn't be failing. I'm only including it here as a reference that matches current Audiobookshelf behavior.

(I've removed some output for brevity and redacted the unique member portion of the URL)

$ curl -Lv 'https://dithering.passport.online/feed/podcast/**********'
* Connected to dithering.passport.online (108.157.150.52) port 443
*  SSL certificate verify ok.
> GET /feed/podcast/********** HTTP/2
> Host: dithering.passport.online
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/2 502
< content-type: text/html
< content-length: 122
< server: awselb/2.0
< date: Wed, 22 Jan 2025 15:14:38 GMT
< x-cache: Error from cloudfront
<

✅ Here's a working example. Note the Accept-Encoding: deflate, gzip request header and the resulting gzipped response.

$ curl --compressed -Lv 'https://dithering.passport.online/feed/podcast/**********'
* Connected to dithering.passport.online (108.157.150.52) port 443
*  SSL certificate verify ok.
> GET /feed/podcast/********** HTTP/2
> Host: dithering.passport.online
> User-Agent: curl/8.7.1
> Accept: */*
> Accept-Encoding: deflate, gzip
> 
* Request completely sent off
< HTTP/2 200 
< content-type: application/xml
< content-length: 93676
< date: Thu, 23 Jan 2025 04:22:57 GMT
< x-atomic-server: passport/v1.1.3-patch.17
< x-atomic-build: f3a5d303
< server: passport/v1.1.3-patch.17
< last-modified: Tue, 21 Jan 2025 10:00:18 GMT
< content-encoding: gzip
< cache-control: public, max-age=86400
< x-cache: Hit from cloudfront
< age: 915
< 
{ [8192 bytes data]
Originally created by @Vynce on GitHub (Jan 23, 2025). Please consider adding an `Accept-Encoding: deflate, gzip` request header to podcast feed downloads and handle the resulting compressed responses. ## Context Audiobookshelf 2.18.1 started to fail fetching one of my podcast member feeds. Something changed in their backend and now only requests that include an `Accept-Encoding` header work. I'm working with their support to see if they can track down the issue on their end, but it still seems worthwhile for Audiobookshelf to support compressed http transactions to reduce bandwidth usage. Looking at the Audiobookshelf logs, there's currently no `Accept-Encoding` header in the feed requests: ``` headers: { Accept: 'application/rss+xml, application/xhtml+xml, application/xml, */*;q=0.8', 'User-Agent': 'audiobookshelf (+https://audiobookshelf.org; like iTMS)' }, ``` ## Examples ❌ Reproducing the issue with curl, here's an example of it failing without compression. To be clear, this is an issue on the server end and shouldn't be failing. I'm only including it here as a reference that matches current Audiobookshelf behavior. (I've removed some output for brevity and redacted the unique member portion of the URL) ``` $ curl -Lv 'https://dithering.passport.online/feed/podcast/**********' * Connected to dithering.passport.online (108.157.150.52) port 443 * SSL certificate verify ok. > GET /feed/podcast/********** HTTP/2 > Host: dithering.passport.online > User-Agent: curl/8.7.1 > Accept: */* > * Request completely sent off < HTTP/2 502 < content-type: text/html < content-length: 122 < server: awselb/2.0 < date: Wed, 22 Jan 2025 15:14:38 GMT < x-cache: Error from cloudfront < ``` ✅ Here's a working example. Note the `Accept-Encoding: deflate, gzip` request header and the resulting gzipped response. ``` $ curl --compressed -Lv 'https://dithering.passport.online/feed/podcast/**********' * Connected to dithering.passport.online (108.157.150.52) port 443 *  SSL certificate verify ok. > GET /feed/podcast/********** HTTP/2 > Host: dithering.passport.online > User-Agent: curl/8.7.1 > Accept: */* > Accept-Encoding: deflate, gzip > * Request completely sent off < HTTP/2 200 < content-type: application/xml < content-length: 93676 < date: Thu, 23 Jan 2025 04:22:57 GMT < x-atomic-server: passport/v1.1.3-patch.17 < x-atomic-build: f3a5d303 < server: passport/v1.1.3-patch.17 < last-modified: Tue, 21 Jan 2025 10:00:18 GMT < content-encoding: gzip < cache-control: public, max-age=86400 < x-cache: Hit from cloudfront < age: 915 < { [8192 bytes data] ```
adam closed this issue 2026-04-25 00:07:58 +02:00
adam commented 2026-04-25 00:07:59 +02:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Feb 12, 2025):

Fixed in v2.19.1.

@github-actions[bot] commented on GitHub (Feb 12, 2025): Fixed in [v2.19.1](https://github.com/advplyr/audiobookshelf/releases/tag/v2.19.1).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#2518
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?