Push Promise Issues

James M Snell <jasnell@gmail.com> Wed, 24 April 2013 16:37 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 []) by ietfa.amsl.com (Postfix) with ESMTP id B104B21F93E6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Apr 2013 09:37:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.569
X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id YJyPezupljdL for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Apr 2013 09:37:48 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org []) by ietfa.amsl.com (Postfix) with ESMTP id B542521F914C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 24 Apr 2013 09:37:47 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UV2gX-0003mN-Ez for ietf-http-wg-dist@listhub.w3.org; Wed, 24 Apr 2013 16:36:45 +0000
Resent-Date: Wed, 24 Apr 2013 16:36:45 +0000
Resent-Message-Id: <E1UV2gX-0003mN-Ez@frink.w3.org>
Received: from maggie.w3.org ([]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UV2gS-0003lO-DX for ietf-http-wg@listhub.w3.org; Wed, 24 Apr 2013 16:36:40 +0000
Received: from mail-oa0-f48.google.com ([]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UV2gR-0005oO-AE for ietf-http-wg@w3.org; Wed, 24 Apr 2013 16:36:40 +0000
Received: by mail-oa0-f48.google.com with SMTP id f4so1901505oah.35 for <ietf-http-wg@w3.org>; Wed, 24 Apr 2013 09:36:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=Ziqg0uyqmxDazndXpxQ3+wtmaTuKHRW4PVfVrANiQHU=; b=IH7UWPA1JU6NxpfHDcwF1JXIcwQzAo4B3AZBZ1V0maG45B01JM7R/PxkOtqjQcLrQI uzc6LJVOuAK6coyGtXUjfJVwnUDcyOrR51xkKzz8Uue35qBv18ZJ1olp5htst6gEAGjt 50SqvIkLXqnbPcDYpV9mzWRAaXnD9cLu/ZXuXUjMj8EGooZzBIBNhX4rU9DN6HB8mPZj Rk5oPyWfW/TwkFZJidnnD3b1ppiWQ+hOnJJ9/GGZqu5W9zQihau8gRvEJG44bJ93/tXK MFef02GsKBb/Q85vcQEhtJHgB6w3r6hJFZZYbi27IRxZxipY73bppFEGuaiEvim6Zls5 fmbg==
X-Received: by with SMTP id n10mr19246568oew.63.1366821373408; Wed, 24 Apr 2013 09:36:13 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 24 Apr 2013 09:35:53 -0700 (PDT)
From: James M Snell <jasnell@gmail.com>
Date: Wed, 24 Apr 2013 09:35:53 -0700
Message-ID: <CABP7RbfbZYAHFztpid-7H6jpMDqGoY6RZFk8MLCbOsjmM1=TZA@mail.gmail.com>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=; envelope-from=jasnell@gmail.com; helo=mail-oa0-f48.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.697, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UV2gR-0005oO-AE 67093121642f7968b3ee8e3d7747d527
X-Original-To: ietf-http-wg@w3.org
Subject: Push Promise Issues
Archived-At: <http://www.w3.org/mid/CABP7RbfbZYAHFztpid-7H6jpMDqGoY6RZFk8MLCbOsjmM1=TZA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17538
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>

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

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.

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.

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.

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