[vlc-devel] [PATCH] vlc_stream/http: add GET_CONTENT_ENCODING
remi at remlab.net
Fri Jul 7 18:00:49 CEST 2017
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
> >> 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.
More information about the vlc-devel