Re: Push Promise Issues

OK, I have made a few clarifying edits for #1.

On 24 April 2013 11:31, James M Snell <jasnell@gmail.com> wrote:
> On Wed, Apr 24, 2013 at 10:25 AM, William Chan (陈智昌)
> <willchan@chromium.org> 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 <jasnell@gmail.com> 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.

In this case, the distinction between error codes doesn't seem
especially important.  The method is idempotent, so regardless of what
the error code says, it's safe to try again.

The only reason I think that CANCEL makes marginally more sense is
that the server has, at the time of the PUSH_PROMISE, committed to
doing something.  If you model PUSH_PROMISE as "I synthesized this GET
request for you on this other stream", then clearly the stream hasn't
been refused by the server.

>>> 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.

I'm not going to touch this one.  Open a design issue if you think
this is important.

Actually, as a side note, I think its best to assume that all
unspecified behavior is prohibited.  We'll get around to closing
loopholes eventually, but using something without defined semantics is
inadvisable.

Received on Thursday, 25 April 2013 18:48:52 UTC