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

[Rémi Denis-Courmont]

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
> user.

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 
automatically detected.

BTW, the patch is actually buggy, insofar as it does not adjust the encoding 
after inflate/decomp.

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.)

> Compressed coding of already compressed content being also possible.

The stream filters can deal with nested compression.

-- 
雷米‧德尼-库尔蒙
https://www.remlab.net/