W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: Questions on Server Push

From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 3 Jun 2013 09:05:45 -0700
Message-ID: <CABkgnnWPuTp41vYDCbbs+PdDOFc7hCVmNzLJq8CsmHe4Jc-8dQ@mail.gmail.com>
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
Received on Monday, 3 June 2013 16:06:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:13 UTC