Re: Push Promise Issues
William Chan (陈智昌) <willchan@chromium.org> Wed, 24 April 2013 17:27 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 090E521F8F12 for
<ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>;
Wed, 24 Apr 2013 10:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.676
X-Spam-Level:
X-Spam-Status: No, score=-9.676 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001,
MIME_8BIT_HEADER=0.3, 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 UJFTxKQ7yZAX for
<ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>;
Wed, 24 Apr 2013 10:27:25 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com
(Postfix) with ESMTP id CF8E721F8F08 for
<httpbisa-archive-bis2Juki@lists.ietf.org>;
Wed, 24 Apr 2013 10:27:24 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from
<ietf-http-wg-request@listhub.w3.org>) id 1UV3Si-0007f9-9a for
ietf-http-wg-dist@listhub.w3.org; Wed, 24 Apr 2013 17:26:32 +0000
Resent-Date: Wed, 24 Apr 2013 17:26:32 +0000
Resent-Message-Id: <E1UV3Si-0007f9-9a@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim
4.72) (envelope-from <willchan@google.com>) id 1UV3SY-0007c8-MO for
ietf-http-wg@listhub.w3.org; Wed, 24 Apr 2013 17:26:22 +0000
Received: from mail-qa0-f42.google.com ([209.85.216.42]) by lisa.w3.org with
esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from
<willchan@google.com>) id 1UV3SX-0004CF-7v for ietf-http-wg@w3.org;
Wed, 24 Apr 2013 17:26:22 +0000
Received: by mail-qa0-f42.google.com with SMTP id dx4so1020685qab.1 for
<ietf-http-wg@w3.org>; Wed, 24 Apr 2013 10:25:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113;
h=mime-version:x-received:sender:in-reply-to:references:date
:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
bh=HB1M3utBDovNLoHDMhkIVttiuvX/dhhZNdv9LLUkX1Y=;
b=O+3/Ri/KltZovrwuM/1ZA38lc7x2DgzGFg3k2dtR/3cE3+c1f76YyUy42nqHJyQEgz
M09L96Kvqi6qdJ96Atsv0yvliRfTn2TgnOV7EgiaHRvoR5ZjY96kPW4M4SRmtuDEpCfc
E9JrTV7fll9r6ArH1B8BuVqdrgDGrv6KUfGv6x8Ms6YvCLPpKfnMOEMe5fO4q0vxml/f
528Mt7evRuFNO8ZYrf0qA9cwZx2mC4CF/kvgDbe7B6/IxpVoUvYiM6MlGMGaZquoJvVV
KEZLaXz57GiD8XhlPJlnwhW+jKS8IQGd0WYTRytU92BJebm/x/zfLBpvGMyHeEDDUJK0 KWvQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google;
h=mime-version:x-received:sender:in-reply-to:references:date
:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
bh=HB1M3utBDovNLoHDMhkIVttiuvX/dhhZNdv9LLUkX1Y=;
b=W7g9iht+ZEw0kFFVfZm5wC++6U3V64lDTAWykKmqbqeZQUFWZMLIt+TQFS7Hz+a//N
aHfYzXWp7TaVvV49OpKWKlpE7qd0a4o7Py3Mt+alCHtc7VhefgeZbygQ1OTtEnVKdZJT
/KUIfu8pRvYVMKcT2/dlNyHxKmKlD1Vn+SiPI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=20120113;
h=mime-version:x-received:sender:in-reply-to:references:date
:x-google-sender-auth:message-id:subject:from:to:cc:content-type
:x-gm-message-state; bh=HB1M3utBDovNLoHDMhkIVttiuvX/dhhZNdv9LLUkX1Y=;
b=ff1mN81HBbjgKLn63YKEzh1jPSBjOZbJEaquH42nPgRRauOjrnLq76GQFv6ckdAGcg
NgWycNwaj24q+yvVxYFm1Fiv/hG3x4P3fn1YqBVs/OEkxI5nTPM9+/yqMZ0Q8Ex/0npH
M958zszf/6b/4M7IFfxd2Vu6FMEH/KVsf92vsynmFASNVOr0GtRBr76VptLwK24/WvdV
fPQd+L93cg9CWMKBqS/x0oSQ2hbMSTv3AaEjnEtwuOHAFACiL3Yv55x7QHRBF9dFb/tQ
ElDU6aqkm+jBH/XaMjzfSkOyAIO1RTdIdIZh2v1I5eDu4Cj5B5Cnoooy4likddwz9mO+ loxQ==
MIME-Version: 1.0
X-Received: by 10.229.131.85 with SMTP id w21mr2455201qcs.71.1366824355477;
Wed, 24 Apr 2013 10:25:55 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.180.4 with HTTP; Wed, 24 Apr 2013 10:25:55 -0700 (PDT)
In-Reply-To: <CABP7RbfbZYAHFztpid-7H6jpMDqGoY6RZFk8MLCbOsjmM1=TZA@mail.gmail.com>
References: <CABP7RbfbZYAHFztpid-7H6jpMDqGoY6RZFk8MLCbOsjmM1=TZA@mail.gmail.com>
Date: Wed, 24 Apr 2013 10:25:55 -0700
X-Google-Sender-Auth: pSgtGv4P3dabJXf9oYXvoF1bPUA
Message-ID: <CAA4WUYgOu70+Gvy4kSiN0g5+fD7iDi5uOAK9TORAjb7+57Hcig@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: James M Snell <jasnell@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=001517576d142e062504db1e987d
X-Gm-Message-State: ALoCoQnPBF6GsmmV86v5vw4A5uFqplxhhfhO0nVk56MXJOKNPkDECAiNqyRhwl3QMzdlzkBxd/yqvpe4ref7g4mFVwfOQJxg/+Dn0qiII+6teiG34MHS2zbRKc/U/pWana6JgD/FUMOp3teQ+nsQ9u9EBwNYReFc7Ofp21K4H3zMlF7LJCUnz97MIbeRsQpQUvRdAdsATy8k
Received-SPF: pass client-ip=209.85.216.42; envelope-from=willchan@google.com;
helo=mail-qa0-f42.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.683, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7,
RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UV3SX-0004CF-7v a182a4a864be66778a53f76e5665b8be
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Push Promise Issues
Archived-At: <http://www.w3.org/mid/CAA4WUYgOu70+Gvy4kSiN0g5+fD7iDi5uOAK9TORAjb7+57Hcig@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17545
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>
I didn't comment on any editorial stuff because I suck at it, but fwiw I agree with your points on all the areas that can/should be clarified. On Wed, Apr 24, 2013 at 9:35 AM, James M Snell <jasnell@gmail.com> wrote: > 1. The process for rejecting a promised stream needs to be clarified. > Right now, section 3.7.5 says, "The PUSH_PROMISE allows the client an > opportunity to reject pushed resources." but does not say any thing > about how such rejection occurs, etc. It's not until section 4.3.2 > that the CANCEL mechanism is briefly described. As an editorial > suggestion, including a forward reference to section 4.3.2. in section > 3.7.5 would be helpful. > > The rejection process described in section 4.3.2 is not very clear and > has a number of issues. The current spec language says: > > To cancel individual server push streams, the > client can issue a stream error (Section 3.5.2) > of type CANCEL. Upon receipt, the server > ceases transmission of the pushed data... > To cancel all server push streams related to a > request, the client may issue a stream error > (Section 3.5.2) of type CANCEL on the > associated-stream-id. By cancelling that stream, > the server MUST immediately stop sending frames > for any streams with in-association-to for the original > stream. > > The way this is worded, the implication is that the client is > cancelling a promised stream that is already in the process of being > transmitted. It's not clear that this is also how a client is to > reject a promised stream *before* transmission begins. Also, it needs > to be made clear that the stream error needs to specify the identifier > of the promised stream and not the associated promising stream. > That is, for example, if stream 1 includes push_promises for streams 3 > and 5, and the client wishes to reject only stream 3, it sends an > RST_STREAM for stream 3. > > 2. If the client is rejecting the promised stream, the error code used > in the RST_STREAM ought to be REFUSED_STREAM and not CANCEL. > Can you explain why? It's not clear to me how a server would handle them differently. I do see that the client may be able to indicate that it has not processed the stream at all, but I'm not sure that matters. On the other hand, I think it's useful in the opposite direction to use REFUSED_STREAM to indicate that it's safe for the client to retry the request. I think there's an editorial issue to clarify that in the spec ( https://github.com/http2/http2-spec/issues/57). > > 3. How long should a client wait for the transmission of a promised > stream? Is there some reasonable timeout? Should the client simply > issue a CANCEL if it feels the stream hasn't been received in a > reasonable period of time? If so, that needs to be described. > I'm not sure this is any different from how long a client would wait for a SYN_REPLY (oops, I mean the HEADERS frame). My client (Chromium) will not time out, but that's up to the client. Typically users will reload the page which will trigger cancellations and resending of a HEADERS+PRIORITY frame. We may also use PING frames for liveness detection, but that would lead us to terminate the entire session. > > 4. In 4.3.1 it is mentioned that the PUSH_PROMISE must include the > :scheme, :host and :port headers. In section 4.3.2, it says :scheme, > :host and :path. I assume that's just a typo in section 4.3.1. > > 5. Section 4.3.1 says that the PUSH_PROMISE SHOULD include header > fields that allow a cache to determine if the resource is already > cached... It should specifically call out a number of headers such as > content-type, etag and last-modified. > > 6. The last paragraph in section 4.3.2 dealing with the mixing of > headers frames and data frames ought to be removed. This really has > nothing to do with Server push and the question of whether we should > allow intermingling of those frame types is still an open question. > > 7. Whether or not a client can send a PUSH_PROMISE to the server needs > to be determined. One can easily envision a use case where a client > wishes to send multiple simultaneous streams to a server. For > instance, sending a PUT or POST to a server that has multiple payloads > (uploading more than one picture or video at a time, for instance). > While such a use case is not currently covered by HTTP/1 semantics, > the new framing layer makes such cases possible and we need to decide > now whether or not we are going to allow it. > > For example, > > A. Client creates a stream to the server with :method=POST, includes > two PUSH_PROMISE frames for two images it wishes to upload... > B. Client sends each image in separate streams with their own HEADERS > frame. > I'm sleep deprived and still confused this morning, but I don't grok this one. Can you explain why a client would send a PUSH_PROMISE rather than a SYN_STREAM (er, a HEADERS+PRIORITY, god my brain still needs to wrap around these new names) frame? PUSH_PROMISE exists to prevent races (having the peer request the resource at the same time that the sender is trying to push it). I don't see how the race exists in the client=>server direction with HTTP semantics, although I can imagine a non-HTTP semantic layering atop the framing layer that might have this race. > > Another case, dealing with the age-old problem of uploading a media > resource and it's associated metadata in a single operation (currently > implemented in many apis as a clumsy MIME package): > > A. Client creates a stream to the server with :method=PUT, includes > two PUSH_PROMISE frames, one for the image, the other for metadata > about the image. > B. Client sends each part in separate streams with their own HEADERS frame. > > In my opinion, these are very compelling use cases that need to be > carefully considered. If clients are allowed to send PUSH_PROMISE > frames, we need to mention it. > > Possibly more later... > > - James > >
- Push Promise Issues James M Snell
- Re: Push Promise Issues William Chan (陈智昌)
- Re: Push Promise Issues James M Snell
- Re: Push Promise Issues Martin Thomson
- Re: Push Promise Issues William Chan (陈智昌)