Re: Push Promise Issues

William Chan (陈智昌) <> Wed, 24 April 2013 17:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 090E521F8F12 for <>; Wed, 24 Apr 2013 10:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.676
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UJFTxKQ7yZAX for <>; Wed, 24 Apr 2013 10:27:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CF8E721F8F08 for <>; Wed, 24 Apr 2013 10:27:24 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UV3Si-0007f9-9a for; Wed, 24 Apr 2013 17:26:32 +0000
Resent-Date: Wed, 24 Apr 2013 17:26:32 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UV3SY-0007c8-MO for; Wed, 24 Apr 2013 17:26:22 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UV3SX-0004CF-7v for; Wed, 24 Apr 2013 17:26:22 +0000
Received: by with SMTP id dx4so1020685qab.1 for <>; Wed, 24 Apr 2013 10:25:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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;; 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 with SMTP id w21mr2455201qcs.71.1366824355477; Wed, 24 Apr 2013 10:25:55 -0700 (PDT)
Received: by with HTTP; Wed, 24 Apr 2013 10:25:55 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 24 Apr 2013 10:25:55 -0700
X-Google-Sender-Auth: pSgtGv4P3dabJXf9oYXvoF1bPUA
Message-ID: <>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <>
To: James M Snell <>
Cc: "" <>
Content-Type: multipart/alternative; boundary=001517576d142e062504db1e987d
X-Gm-Message-State: ALoCoQnPBF6GsmmV86v5vw4A5uFqplxhhfhO0nVk56MXJOKNPkDECAiNqyRhwl3QMzdlzkBxd/yqvpe4ref7g4mFVwfOQJxg/+Dn0qiII+6teiG34MHS2zbRKc/U/pWana6JgD/FUMOp3teQ+nsQ9u9EBwNYReFc7Ofp21K4H3zMlF7LJCUnz97MIbeRsQpQUvRdAdsATy8k
Received-SPF: pass client-ip=;;
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: 1UV3SX-0004CF-7v a182a4a864be66778a53f76e5665b8be
Subject: Re: Push Promise Issues
Archived-At: <>
X-Mailing-List: <> archive/latest/17545
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-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 <> 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 (

> 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