Re: Push Promise Issues

[James M Snell <[e-mail]>]

On Wed, Apr 24, 2013 at 10:25 AM, William Chan (陈智昌)
<[e-mail]> wrote:
> I didn't comment on any editorial stuff because I suck at it, but fwiw I
> agree with your points on all the areas that can/should be clarified.
>
> On Wed, Apr 24, 2013 at 9:35 AM, James M Snell <[e-mail]> wrote:
>>
[snip]
>>
>> 2. If the client is rejecting the promised stream, the error code used
>> in the RST_STREAM ought to be REFUSED_STREAM and not CANCEL.
>
>
> Can you explain why? It's not clear to me how a server would handle them
> differently. I do see that the client may be able to indicate that it has
> not processed the stream at all, but I'm not sure that matters. On the other
> hand, I think it's useful in the opposite direction to use REFUSED_STREAM to
> indicate that it's safe for the client to retry the request. I think there's
> an editorial issue to clarify that in the spec
> (https://github.com/http2/http2-spec/issues/57).
>

The main reason is that there is a difference between a client no
longer needing a pushed stream vs. not wanting it at all. For
instance, if the client navigates away from a page, the stream being
pushed is CANCELed. If the client returns back to that page later,
then the server will likely attempt to push the resource again. If,
however, the client refuses a pushed stream because the pushed
resource is unacceptable in some manner, then the server might choose
to not attempt pushing the resource again later on (obviously there
are quite a few assumptions about managed state being made in that
example). The bottom line is that I do not think we should make too
many assumptions about how a server will handle the difference between
the two cases.

>>
>>
>> 3. How long should a client wait for the transmission of a promised
>> stream? Is there some reasonable timeout? Should the client simply
>> issue a CANCEL if it feels the stream hasn't been received in a
>> reasonable period of time? If so, that needs to be described.
>
>
> I'm not sure this is any different from how long a client would wait for a
> SYN_REPLY (oops, I mean the HEADERS frame). My client (Chromium) will not
> time out, but that's up to the client. Typically users will reload the page
> which will trigger cancellations and resending of a HEADERS+PRIORITY frame.
> We may also use PING frames for liveness detection, but that would lead us
> to terminate the entire session.
>

I tend to agree, but it needs to be stated explicitly if this is the
case. Some simple statement along the lines of: A client can send a
CANCEL if the server takes too long to send a promised stream... etc

[snip]
>>
>> 7. Whether or not a client can send a PUSH_PROMISE to the server needs
>> to be determined. One can easily envision a use case where a client
>> wishes to send multiple simultaneous streams to a server. For
>> instance, sending a PUT or POST to a server that has multiple payloads
>> (uploading more than one picture or video at a time, for instance).
>> While such a use case is not currently covered by HTTP/1 semantics,
>> the new framing layer makes such cases possible and we need to decide
>> now whether or not we are going to allow it.
>>
>>
>> For example,
>>
>> A. Client creates a stream to the server with :method=POST, includes
>> two PUSH_PROMISE frames for two images it wishes to upload...
>> B. Client sends each image in separate streams with their own HEADERS
>> frame.
>
>
> I'm sleep deprived and still confused this morning, but I don't grok this
> one. Can you explain why a client would send a PUSH_PROMISE rather than a
> SYN_STREAM (er, a HEADERS+PRIORITY, god my brain still needs to wrap around
> these new names) frame? PUSH_PROMISE exists to prevent races (having the
> peer request the resource at the same time that the sender is trying to push
> it). I don't see how the race exists in the client=>server direction with
> HTTP semantics, although I can imagine a non-HTTP semantic layering atop the
> framing layer that might have this race.
>

The idea is simply sending multiple request payloads with a single
http operation.. a POST with N-number individual associated streams,
for instance. Uploading photos is one use case, adding items to an
Atom Publishing Collection is another. Right now much of this is done
using clunky multipart mime formats. It could be done more efficiently
with multiplexed streams.

- James

>>
>>
>> Another case, dealing with the age-old problem of uploading a media
>> resource and it's associated metadata in a single operation (currently
>> implemented in many apis as a clumsy MIME package):
>>
>> A. Client creates a stream to the server with :method=PUT, includes
>> two PUSH_PROMISE frames, one for the image, the other for metadata
>> about the image.
>> B. Client sends each part in separate streams with their own HEADERS
>> frame.
>>
>> In my opinion, these are very compelling use cases that need to be
>> carefully considered. If clients are allowed to send PUSH_PROMISE
>> frames, we need to mention it.
>>
>> Possibly more later...
>>
>> - James
>>
>