[vlc-devel] [PATCH 1/3] libvlccore: Add STREAM_GET_HTTP_HEADER control

Rémi Denis-Courmont remi at remlab.net
Mon Aug 12 18:19:08 CEST 2019


Le maanantaina 12. elokuuta 2019, 19.14.02 EEST Alexandre Janniaux a écrit :
> Hi,
> 
> On Mon, Aug 12, 2019 at 06:56:12PM +0300, Rémi Denis-Courmont wrote:
> > Le maanantaina 12. elokuuta 2019, 18.52.55 EEST Marvin Scholz a écrit :
> > > On 12 Aug 2019, at 17:49, Rémi Denis-Courmont wrote:
> > > > Le maanantaina 12. elokuuta 2019, 18.45.59 EEST Marvin Scholz a écrit 
:
> > > >> On 12 Aug 2019, at 15:19, Rémi Denis-Courmont wrote:
> > > >>> Hi,
> > > >>> 
> > > >>> I think you're missing the point here. You can't just pass opaque
> > > >>> data
> > > >>> through filters, and you don't control what header lines get sent or
> > > >>> when. This is the block flags discussion all over again. What you're
> > > >>> doing just isn't a good fit with the stream abstraction.
> > > >> 
> > > >> I don't see how this is related to block flags, this is stream level
> > > >> metadata and the http headers do not change
> > > >> mid-stream, do they?
> > > > 
> > > > Sure they do.
> > > 
> > > Oh, how? My understanding is that they are sent at the beginning of the
> > > response and do not change?
> > 
> > RTFS.
> 
> What does RTFS means ?

Read The Fine Source.

> You mean it can change because of chunk transfer encoding ?

No. I mean that, because this patch violates layering and in doing so, ends up 
wrongly assuming that there is exactly one HTTP request/response pair per 
access. Not only would that be an implementation detail, but it is simply not 
true even now.

To control HTTP requests and responses tightly, you need to use the 
corresponding lower level interfaces, i.e. vlc_http_{req,resp}.

-- 
Rémi Denis-Courmont
http://www.remlab.net/





More information about the vlc-devel mailing list