On Thu, 28 May 2015, Lucas Pardue wrote:

> Interesting proposal.

Thanks. I figure we have to start somewhere. It is easier to discuss and argue
for and against an existing proposal.

Allow me to continue brainstorming on this...

>> This is how the callback would work:
>>
>> int curl_stream_push(CURL *newhandle,
>> unsigned int stream_id,
>> struct curl_push *headers,
>> void *userp);
>
> Does stream_id represent the stream the PUSH_PROMISE was received on, or the
> promised Stream ID? How useful are either of those IDs to the application?

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.

>> struct curl_push {
>> const char *method; /* example: "GET" */
>> const char *path; /* example: "/download-154/image.png" */
>> const char *scheme; /* example: "https" */
>> const char *authority; /* example: "www.example.com:443" */ };
>
> How would you pass back additional header fields contained in the
> PUSH_PROMISE to the application?

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?

> Could they be added to struct curl_push? Or would a callback like
> CURLOPT_HEADERFUNCTION be more appropriate?

Using that callback seems a bit quirky for this purpose. I want to this
callback to say OK/DENY for the new stream and thus I would it to have all the
necessary info to make that decision.

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?

>> The 'newhandle' is a newly created easy handle that represents this new
>> transfer. This handle is otherwise "naked" and will need a suitable set of
>> options set before it will work the way the application wants it to.
>
> Could there be a way for the new handle to automatically assume options? For
> example, 'inherit' the options used for the initial GET request handle, or
> assume a configured default set.

Oh, I really like that idea!

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 callback would have to tell libcurl somehow which handle to copy options
from...

A slightly more generic way would be to introduce a libcurl copy-options
function that would copy over all options from a single handle onto another.
Still requires the application to have a "base" handle to copy from.

I guess a typical application that supports push would perhaps create a
"dummy" handle just for the sake of copying from whenever new streams are
pushed.

That gave me an alternative idea! A new easy option that tells libcurl that
this is just a "push handle template". If you create an easy handle and all
options you like and this "PUSH_TEMPLATE" option, when you add that to an easy
handle it doesn't create any transfer in itself but that handle is _only_ used
on subsequent pushes to clone options from.

What do you think?

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html