Questions on Server Push

Shigeki Ohtsu <ohtsu@iij.ad.jp> Fri, 31 May 2013 10:02 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A53721F92F5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 31 May 2013 03:02:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.399
X-Spam-Level:
X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_48=0.6, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oz1EuotUhQAG for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 31 May 2013 03:02:30 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 33F0B21F8793 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 31 May 2013 03:02:27 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UiM8C-00011p-7h for ietf-http-wg-dist@listhub.w3.org; Fri, 31 May 2013 10:00:20 +0000
Resent-Date: Fri, 31 May 2013 10:00:20 +0000
Resent-Message-Id: <E1UiM8C-00011p-7h@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <ohtsu@iij.ad.jp>) id 1UiM7t-0005fo-T3 for ietf-http-wg@listhub.w3.org; Fri, 31 May 2013 10:00:01 +0000
Received: from mo30.iij.ad.jp ([202.232.30.71] helo=omgo.iij.ad.jp) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <ohtsu@iij.ad.jp>) id 1UiM7s-0000PH-85 for ietf-http-wg@w3.org; Fri, 31 May 2013 10:00:01 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iij.ad.jp; h=Message-ID: Date:From:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; i= ohtsu@iij.ad.jp; s=omgo1; t=1369994376; x=1371203976; bh=TuhmtecOyuggXAmzTPDOQy10 5zyYBHystwMJZrCNnR4=; b=H6g0UOEubGi0GSYGjvlx1E47GhnYC4JjbH6jAPU+t9hYEePrPmYuxQ N/Q5wUhMzCRrAR3GWJ7MD+dooNpwkWsR/MnIsCgO4wzSu1GpcV07AbDrkUmXDmva7/USmrnofYKEs PKmlKIIHw13qXJ0upP82tB9aFcVqX7JgPuUaSvbM=;
Received: by omgo.iij.ad.jp (mo30) id r4V9xaYM028665; Fri, 31 May 2013 18:59:36 +0900
Message-ID: <51A87484.4090501@iij.ad.jp>
Date: Fri, 31 May 2013 18:59:32 +0900
From: Shigeki Ohtsu <ohtsu@iij.ad.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=202.232.30.71; envelope-from=ohtsu@iij.ad.jp; helo=omgo.iij.ad.jp
X-W3C-Hub-Spam-Status: No, score=-1.2
X-W3C-Hub-Spam-Report: DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.07, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UiM7s-0000PH-85 fa170d6b11369711fae6beb48807c09c
X-Original-To: ietf-http-wg@w3.org
Subject: Questions on Server Push
Archived-At: <http://www.w3.org/mid/51A87484.4090501@iij.ad.jp>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18155
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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.

Regards,

==================================================================
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?