[vlc-devel] [PATCH] vlc_stream/http: add GET_CONTENT_ENCODING
remi at remlab.net
Thu Jul 6 23:33:38 CEST 2017
Le torstaina 6. heinäkuuta 2017, 23.14.14 EEST Francois Cartegnie a écrit :
> Le 06/07/2017 à 19:56, Rémi Denis-Courmont a écrit :
> > Specifically, you cannot distinguish between a resource whose only
> > representation is in compresssed form, and a resource that has both
> > compressed and uncompressed representation. Some servers expose both
> > cases in the same way, with the Content-Encoding header (or not).
> If we could explicitly request identity the server would not return
> compressed coding. stream_Url now returns an unexpected encoding to the
That really does not explain why you need this patch. The decompression stream
filters do not need the Content-Encoding, since deflate and gzip can easily be
BTW, the patch is actually buggy, insofar as it does not adjust the encoding
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
> Compressed coding of already compressed content being also possible.
The stream filters can deal with nested compression.
More information about the vlc-devel