[Privoxy-users] issue with gzip content-encoding and range queries

Fabian Keil fk at fabiankeil.de
Wed Jun 29 13:34:06 UTC 2016

Thorsten von Eicken <tve at voneicken.com> wrote:

> I've been running into problems with streaming media files on android 
> devices. Specifically, seeking in mp3 files using range headers doesn't 
> work. Using a stock install of 3.0.25 on debian I see the following. I 
> bring up a page with some embedded audio player (for a podcast). I can 
> play, but if I seek I get a very short sound burst and then the player 
> jumps to the end. Disabling privoxy doesn't help. Going straight to the 
> server (i.e. no proxy at all) works great too. Using desktop chrome 
> works fine with privoxy.
> I ran some tcpdumps and see that the requests have Accept-Encoding:gzip 
> and the response has Content-Encoding: gzip
> and Transfer-Encoding: chunked. When I seek in the audio the device uses 
> range requests, for example, Range: bytes=9854244-.  I then added a rule 
> to privoxy to drop the Accept-Encoding header 
> (+crunch-client-header{Accept-Encoding}) and with that it all works 
> great. I have had the same issue on other sites, so it's not a site 
> specific problem.
> Does this problem description ring a bell?
> Steps to reproduce:
> - install privoxy 3.0.25 beta from source on debian, stock config file 
> (except I had to change the listening port)
> - grab an android device with chome
> - navigate to http://www.unlearnandrewild.org/listen/
> - play the first podcast and a second or two after it starts seek 
> forward by pressing into the bar
> - the player will briefly display the time you seeked to and then jump 
> to the end of the podcast
> Sample request/response header:
> GET 
> http://deepgreens.org/UnlearnAndRewild/UnlearnAndRewildLo-Fi/UnlearnAndRewild-035-RobinWallKimmerer-Lo.mp3 
> HTTP/1.1
> User-Agent: stagefright/1.2 (Linux;Android 5.1.1)
> allow-cross-domain-redirect: false
> Range: bytes=9854244-
> Host: deepgreens.org
> Connection: Keep-Alive
> Accept-Encoding: gzip
> HTTP/1.1 200 OK
> Date: Wed, 29 Jun 2016 06:30:42 GMT
> Server: Apache/2.4.12
> Last-Modified: Fri, 13 May 2016 21:48:31 GMT
> ETag: "8ea08b6-197bfc3-532c03c60451b-gzip"
> Accept-Ranges: bytes
> Vary: Accept-Encoding,User-Agent
> Content-Encoding: gzip
> Connection: Keep-Alive
> Transfer-Encoding: chunked
> Content-Type: audio/mpeg
> Proxy-Connection: keep-alive

I don't use Android or Chrome, but can reproduce the issue with curl:

fk at r500 ~ $curl --head -H 'Range: bytes=9854244-' -H "Accept-Encoding: gzip" 'http://deepgreens.org/UnlearnAndRewild/UnlearnAndRewildLo-Fi/UnlearnAndRewild-035-RobinWallKimmerer-Lo.mp3'
HTTP/1.1 200 OK
Date: Wed, 29 Jun 2016 13:31:01 GMT
Server: Apache/2.4.12
Last-Modified: Sun, 19 Jun 2016 05:48:15 GMT
ETag: "8ea08b6-197bfc3-532c03c60451b-gzip"
Accept-Ranges: bytes
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Type: audio/mpeg

fk at r500 ~ $curl --head -H 'Range: bytes=9854244-' 'http://deepgreens.org/UnlearnAndRewild/UnlearnAndRewildLo-Fi/UnlearnAndRewild-035-RobinWallKimmerer-Lo.mp3'
HTTP/1.1 206 Partial Content
Date: Wed, 29 Jun 2016 13:31:11 GMT
Server: Apache/2.4.12
Last-Modified: Sun, 15 May 2016 21:58:47 GMT
ETag: "8ea08b6-197bfc3-532c03c60451b"
Accept-Ranges: bytes
Content-Length: 16867999
Vary: Accept-Encoding,User-Agent
Content-Range: bytes 9854244-26722242/26722243
Content-Type: audio/mpeg
Proxy-Connection: keep-alive

If the Accept-Encoding header is present the server ignores the
Range request (status code 200), without the header the Range
request is honoured (status code 206, Content-Range specified).

This is valid behaviour, but it's not uncommon for multimedia
clients to handle it poorly.

I see the same behaviour when Privoxy isn't involved,
but it's conceivable that your client sends different
headers when not using a proxy.

It might help to sniff the traffic when seeking without
Privoxy to confirm this.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.privoxy.org/pipermail/privoxy-users/attachments/20160629/76f69c87/attachment.bin>

More information about the Privoxy-users mailing list