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