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

Questions on Server Push

From: Shigeki Ohtsu <ohtsu@iij.ad.jp>
Date: Fri, 31 May 2013 18:59:32 +0900
Message-ID: <51A87484.4090501@iij.ad.jp>
To: HTTP Working Group <ietf-http-wg@w3.org>
Hi all,

After I finished reading draft-03, I have several questions
(Q1,2 and 3 in below) of the frame sequences in server push.

I might have missed something on the spec, please give me
the right answers.


In 4.2.2.  Request, it says that
"The client initiates a request by sending a HEADERS+PRIORITY frame.
Requests that do not contain a body MUST set the FINAL flag,
indicating that the client intends to send no further data on this
stream, unless the server intends to push resources (see
Section 4.3)."

Suppose the two cases with/without server push below, the frame
sequences are

A: Without Server Push
1. Client -> HEADERS+PRIORITY with FINAL(Get Request) -> Server
2. Client <- HEADERS(Response)  <- Server
3. Client <- DATA with FINAL(Response) <-Server

B: With Server Push
1. Client -> HEADERS+PRIORITY(Get Request)  -> Server
2. Client <- PUSH_PROMISE <- Server
3. Client <- HEADER(Promised Response) <- Server
4. Client <- DATA(Promised Response) with FINAL <- Server
5. Client <- HEADER(Response) <- Server
6. Client <- DATA with FINAL(Response) <-Server

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.

Q1: How can the client know that the content is to be pushed by the
server beforehand?

Q2: In case of B, the stream is in a half-closed state after 6.
How can I make it full-closed?
Does the client need to send a empty DATA frame with FINAL to
the server at the last step?

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

Suppose that server push is performed after HTTP/1.1 upgrade as below, steps are

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

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.
To avoid this, do we need to send HEADER in step6 before PUSH_PROMISE in step5?
Received on Friday, 31 May 2013 10:00:01 UTC

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