[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.
Francois
More information about the vlc-devel
mailing list