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?

> 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
Received on 2015-05-28