On Thu, May 28, 2015 at 11:26 PM Lucas Pardue <Lucas.Pardue_at_bbc.co.uk>
wrote:

> On Thu, 28 May 2015, Daniel Stenberg wrote:
>
> > Thanks. I figure we have to start somewhere. It is easier to discuss and
> argue
> > for and against an existing proposal.
>
> My experience developing with libcurl is limited so my thoughts may not
> reflect how others would approach HTTP(/2). Just a warning if anything
> seems a little odd.
>
> > I figured it would be the new promised Stream ID. But so far we have
> nothing
> > in the API exposing the Stream ID of an existing stream so I'm not sure
> it is
> > actually needed or fit any particupar purpose.
>
> I tend to agree, exposing the stream IDs brings out information that will
> reduce compatibility with HTTP/1.1. I presume that libcurl would handle all
> of the stream ID validation defined in the specification.
>
> > With that design, it would need some extra stuff. You think we should
> > instead make it possible to truly get all headers the server sends?
> >
> > Do you have a particular use case in mind for when you want other
> headers?
>
> I can't find many examples of server push to date, so its not clear what
> header fields would be set, in practice, in the PUSH_PROMISE. "Accept*" and
> "Referer" fields perhaps. Cookies?
>
>
There is no exact guidance to which header should be included in
PUSH_PROMISE. I imagine that each implementation does its own way.
For nghttpx, we copy accept-encoding, accept-language, cache-control, host
and user-agent from associated stream's request headers if they exist.
First I thought we need accept, cookie, and authorization as well. But it
seems browser changes accept header field depending on the type of the
resource it is requesting. For the latter 2, I'm not sure it is ok to echo
back to client in term of security.

Best regards,
Tatsuhiro Tsujikawa

> > Maybe we can provide those "standard" headers using the struct, and then
> > provide the remainder of the headers in some sort of list or hash?
>
> Yes that sounds sensible. Maybe not optimal if nobody will ever care to
> check the headers though. Hard to anticipate user needs.
>
> > There isn't any "natural" easy handle to inherit from though, as all easy
> > handles are the existing streams and the PUSH_PROMISE makes a new one
> > without a clear parent.
>
> The PUSH_PROMISE will be sent on the stream created by the initial
> request. Is that not a natural parent?
>
> My thought process for this assumed option behaviour is that you probably
> want an OK/DENY answer from the application as quickly as possible. In
> order to have time to send the RST_STREAM to the server before it starts
> sending data. The important bit for the client is probably that it gets to
> set the correct options to write the pushed data somewhere.
>
> Taking a step back. Do all options really need to be set in this pushed
> handle? For example, CURLOPT_HTTP_VERSION would be implicitly
> CURL_HTTP_VERSION_2_0, but then it's not going to be used to control
> outgoing request behaviour in libcurl. The same argument could be used for
> many transport related options. Maybe this auto/assumed behaviour is
> over-engineering for what a typical user would want to (and can already) do.
>
> Lucas
>
>
> -----------------------------
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and
> may contain personal views which are not the views of the BBC unless
> specifically stated.
> If you have received it in
> error, please delete it from your system.
> Do not use, copy or disclose the
> information in any way nor act in reliance on it and notify the sender
> immediately.
> Please note that the BBC monitors e-mails
> sent or received.
> Further communication will signify your consent to
> this.
> -----------------------------
>
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-05-28