[vlc-devel] [PATCH] vlc_stream/http: add GET_CONTENT_ENCODING

Francois Cartegnie fcvlcdev at free.fr
Fri Jul 7 11:19:23 CEST 2017

Le 06/07/2017 à 23:33, Rémi Denis-Courmont a écrit :
> And for the record, Accept-Encoding: identity is purposedly not sent.  
> Compressed data is desirable in some cases. That is to say, when seeking is 
> useless and data compresses well, such as large text/* files. The old HTTP 
> interface operated the same way. More importantly, sending the header can 
> cause negotiation failure if the entity is available only in compressed form.
> (On the other hand, some misconfigured servers compress too eagerly if 
> "Accept-Encoding: gzip" is passed, e.g. Apache mod_deflate. This is known to 
> break seeking of MP3 streams notably. Hence, not sending Accept-Encoding at 
> all.)

If server adds encoding without consent, then you need to handle every
rfc declared content encoding by StreamUrl users.

>> Compressed coding of already compressed content being also possible.
> The stream filters can deal with nested compression.

That still does not solve the case from a streamUrl point of view.
The user expects identity content and should not have to deal with
stream_filters (see above).

If I want a stream retrieving a tar.gz through streamUrl there's no
reason to receive a tar because I had to install deflate filter in case
additional content encoding.

This is known to currently break streamUrl uses, and the lua deflate
hack creates a new bug for scripts retrieving compressed files.

Removing the extra declared additional content-coding should be done at
wrapper level. Dealing with unwanted compression for mp3 and such being
a specific case for input access chain.


More information about the vlc-devel mailing list