RE: Questions on Server Push

[Mike Bishop <[e-mail]>]

Streams get half-closed from each side.  Stream 1 is half-closed by the client, not half-closed by the server.  A stream is closed when each side has half-closed.

Is there a wording clarification that would help make this plainer?

-----Original Message-----
From: Shigeki Ohtsu [mailto:[e-mail]] 
Sent: Monday, June 3, 2013 5:02 PM
To: Martin Thomson
Cc: HTTP Working Group
Subject: Re: Questions on Server Push

Thanks for your answer. Please let me clarify it.

(2013/06/04 1:05), Martin Thomson wrote:
> On 31 May 2013 02:59, Shigeki Ohtsu <[e-mail]> wrote:
>> In the above B case, FINAL flag cannot be set in HEADERS+PRIORITY so
>>   we need to know it at first to distinguish the case A.
>
> This isn't quite right.  Only the stream from the server to the client 
> (the response stream) needs to be open in order to send PUSH_PROMISE.

In 4.3.1 Server implementation, it says that "A server cannot send a PUSH_PROMISE on a new stream or a half-closed stream."

If the following is permitted

  1. Client -> HEADERS+PRIORITY with FINAL (Get Request) -> Server (stream 1)
(stream1 is half-closed)
  2. Client <- PUSH_PROMISE <- Server (stream 1)
  3. Client <- HEADER(Promised Response) <- Server (stream 2)
  4. Client <- DATA(Promised Response) with FINAL <- Server (stream 2)
  5. Client <- HEADER(Response) <- Server (stream 1)
  6. Client <- DATA with FINAL(Response) <-Server (stream 1)
(stream1 is full-closed)

then  PUSH_PROMISE on step2 seemed to be sent from server on the half-closed stream 1. Do we need to change the spec so as to permit to send PUSH_PROMISE on a half-closed stream?

> Also, the ordering isn't strictly this way.  Steps 3,4 and 5,6 can be 
> interleaved in any order.  The only constraint is that step 6 (the one 
> containing the FINAL for stream 1) comes after step 2.

This was the another question that came into my mind, but I wrote the example
  to follow the current SPDY case. It was solved, thanks.

We would be glad if you add some notes about this after "After sending a PUSH_PROMISE, the server commences transmission of a pushed resource."
in 4.3.1.

It might be also related to the description to be written about the stream lifecycles as noted on http://http2.github.io/http2-spec/#rfc.comment.5

>> Q3: In above case, no stream was created before step 5 so that 
>> PUSH_PROMISE was sent on a new stream. This is forbidden in the spec.
>
> This is a case that we haven't completely resolved yet.  My 
> expectation is that we will define something like: the pre-Upgrade
> request implicitly opens stream 1.   See
> https://github.com/http2/http2-spec/issues/52

Thanks, I missed to find the issue.
It would be nice to have the first implicit client-initiated stream
  which has a default priority. The sequence would be

1. Client -> Get Request(HTTP/1.1) with Upgrade -> Server (open implicit stream 1 with a default priority) 2. Client <- 101 Switch Protocol Response <- Server 3. Client <- Connection Header + SETTINGS <- Server 4. Client -> Connection Header + SETTINGS -> Server 5. Client <- PUSH_PROMISE <- Server (implicit stream 1) 6. Client <- HEADER(Promised Response) <- Server (stream 2) 7. Client <- DATA(Promised Response) with FINAL <- Server (stream 2) 8. Client <- HEADER(Response) <- Server (implicit stream 1) 9. Client <- DATA with FINAL(Response) <-Server (implicit stream 1)

Regards,