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 [127.0.0.1]) 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-Level:
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [128.30.52.56]) 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 ([128.30.52.39]) 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 ([209.85.219.48]) 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 10.60.76.234 with SMTP id n10mr19246568oew.63.1366821373408; Wed, 24 Apr 2013 09:36:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.3.137 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=209.85.219.48; 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 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. 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
- Re: Push Promise Issues William Chan (陈智昌)
- Push Promise Issues James M Snell
- Re: Push Promise Issues James M Snell
- Re: Push Promise Issues Martin Thomson
- Re: Push Promise Issues William Chan (陈智昌)