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

[Rémi Denis-Courmont]

Le perjantaina 7. heinäkuuta 2017, 11.19.23 EEST Francois Cartegnie a écrit :
> > (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.

This has been discussed at length on Trac, and possibly here.

In principles, VLC should expose gzip and deflate. But that is known to break 
GetSize and Seek for some streams. So instead, VLC sends nothing. Forcing 
"identity" would be plain wrong.

Unsupported encoding would fail one way or another. I doubt that a server 
would send a new encoding unless either it is the only available 
representation for the entity, or the client explicitly exposed support for 
the encoding.

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

I totally disagree.

The HTTP transaction layer needs to handle transfer encoding. The URL layer 
should handle content encoding.

Ideally, the Content-Type should match what comes from the URL layer, without 
any encoding. So if the Content-Type is "application/gzip", then ideally, we 
would leave it at that. But that distinction only makes sense for HTTP, so it 
can´t work generically.

And it´s VLC media player, not VLC download manager.

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

To the contrary, there is. HTTP does not assign semantics to filename 
extensions. It´s entirely valid (and possible with e.g. Apache content 
negotiation) to get a gzipped tarball, when requesting a tarball.

The intent of the protocol, and of our implementation, if gzip is set as 
Content-Encoding is to undo that encoding. 

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

No. It´s working as it should. The last thing I want is every stream-URL use 
site is duplicating decompression support and implementing different subsets 
of encoding with different bugs.

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

I totally disagree.

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