Support » Plugin: Seriously Simple Podcasting » Support for HTTP “range” requests

  • Resolved cconstantine


    I’m trying to troubleshoot a problem reported with the Google Podcasts player on Android. (I’ve one reporting user and I cannot personally reproduce the problem.) In the process, I went down a rabbit hole looking into HTTP range requests.

    I’m wondering: If the the SSP plugin is serving the MP3 audio files via PHP (which would require the PHP code to implement supporting range requests) or if, after a redirection from the stats-collection URL, it let’s my web server (Apache) just send out the static file (in which case Apache itself handles range requests.)


    The page I need help with: [log in to see the link]

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Author Jonathan Bossenger


    @cconstantine thanks for getting in touch.

    Do you perhaps have a URL describing HTTP range requests and how they relate to serving files behind the PHP redirect, so that I can understand how it could be causing the problem? From the cursory review I’ve done, it would appear we should update the plugin to support range requests, would you agree?


    …I think it’s not actually a problem, but I wanted to doublecheck my analysis with someone familiar with the code.

    For range requests, it’s [RFC7233]( — but before even bother looking at that. I think the answer is that SSP doesn’t handle the serving of the audio file via PHP, but rather leaves that to the underlying web server. (In my case, that’s Apache, which handles range requests of static assets.)

    Straight from my RSS feed, I have (for example) <enclosure url="" length="29493071" type="audio/mpeg"></enclosure> and if I fetch that URL, I get SSP doing a redirection. Here I’m asking Curl to get me a range of bytes:

    Craigs-iMac:~ craig$ curl -I --range 500-600
    HTTP/1.1 302 Found
    Date: Fri, 11 Oct 2019 14:55:48 GMT
    Server: Apache
    Pragma: no-cache
    Expires: 0
    Cache-Control: must-revalidate, post-check=0, pre-check=0
    Robots: none
    X-Redirect-By: WordPress
    Set-Cookie: PHPSESSID=6576b49ab4d78ab7628bb05a727805dd; path=/
    Content-Type: text/html; charset=UTF-8

    …gives me a standard redirection. As expected since SSP wants to track statistics. That new location is a direct-link into the WP assets storage. When I Curl that, making a range request again, it works perfectly. (Apache is happy to give 101 bytes.) Below is both the headers-only (-I in Curl) and full fetch….

    Craigs-iMac:~ craig$ curl -I --range 500-600
    HTTP/1.1 206 Partial Content
    Date: Fri, 11 Oct 2019 14:58:33 GMT
    Server: Apache
    Last-Modified: Sun, 06 Oct 2019 14:51:01 GMT
    Accept-Ranges: bytes
    Content-Length: 101
    Vary: Accept-Encoding
    Content-Range: bytes 500-600/29493071
    Content-Type: audio/mpeg
    Craigs-iMac:~ craig$ curl --range 500-600 > ./foo
      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
    100   101  100   101    0     0    389      0 --:--:-- --:--:-- --:--:--   388
    Craigs-iMac:~ craig$ ls -alh ./foo
    -rw-r--r--  1 craig  staff   101B Oct 11 10:58 ./foo

    So I think the answer is SSP doesn’t interfere with HTTP range requests. And that means the problem I’m trying to solve can’t be caused by my site not correctly answering range requests.

    Further digging revealed that our Apache server was [mis]configured to apply the DEFLATE module (aka gzip) to media files. Turns out that content-encoding (not to be confused with transfer-encoding) is not compatible with range HTTP requests.

    Plugin Author Jonathan Bossenger


    @cconstantine thanks for the update. I’ll see if we can get this added to our support documents.

Viewing 4 replies - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.