- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Mon, 3 Jun 2013 09:05:45 -0700
- To: Shigeki Ohtsu <ohtsu@iij.ad.jp>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 31 May 2013 02:59, Shigeki Ohtsu <ohtsu@iij.ad.jp> 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. Note also that your example doesn't show that the pushed resource is on a different stream to original request. e.g.: 1. Client -> HEADERS+PRIORITY(Get Request) -> Server (stream 1) 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) 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. > 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
Received on Monday, 3 June 2013 16:06:12 UTC