<p dir="ltr">Hello,</p>
<p dir="ltr">Le 13 sept. 2016 11:20 AM, Francois Cartegnie <fcvlcdev@free.fr> a écrit :<br>
><br>
> Le 12/09/2016 à 20:07, Francois Cartegnie a écrit :<br>
><br>
> Seems mailman disabled my account for unknown reason.<br>
><br>
> > Plus the performance will suck if you don't reuse the HTTP connection manager <br>
> > across ranges.<br>
><br>
> > In other words, I can't see this working properly through the VLC stream <br>
> > abstraction, as opposed to using vlc_http_resource et al. directly.<br>
><br>
> I don't see how we could properly handle gzip and other stream filters<br>
> if we work at the same level than access.</p>
<p dir="ltr">Red herring. You cannot handle gzip/deflate content-encoding with byte ranges by HTTP protocol design. Not in stream filters, not in access, not in demux, not anywhere.<br></p>
<p dir="ltr">> This would also mean duplicating the whole access.c code for dealing<br>
> with cookies and keystore, as well as the file.c code and callbacks to<br>
> handle byte range and disable any content/transfert encoding which would<br>
> require stream_filter.</p>
<p dir="ltr">What? Cookies are handled by the connection manager (and the playlist). http/access.c and http/file.c have nothing to do with cookies.</p>
<p dir="ltr">Passwords are handled by the keystore which is not even part of the HTTP plugin at all, while HTTP authentication proper is handled in common HTTP lower layers (resource.c and message.c).<br>
</p>