Re: Push Promise Issues

Martin Thomson <martin.thomson@gmail.com> Thu, 25 April 2013 18:50 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 6BBFC21F9662 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 25 Apr 2013 11:50:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 kNOjDE0UITLd for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 25 Apr 2013 11:50:04 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id B03D021F9644 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 25 Apr 2013 11:50:04 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UVRE1-0007Nk-MX for ietf-http-wg-dist@listhub.w3.org; Thu, 25 Apr 2013 18:48:57 +0000
Resent-Date: Thu, 25 Apr 2013 18:48:57 +0000
Resent-Message-Id: <E1UVRE1-0007Nk-MX@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1UVRDw-0007MW-Av for ietf-http-wg@listhub.w3.org; Thu, 25 Apr 2013 18:48:52 +0000
Received: from mail-wg0-f44.google.com ([74.125.82.44]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1UVRDr-0005WL-M3 for ietf-http-wg@w3.org; Thu, 25 Apr 2013 18:48:52 +0000
Received: by mail-wg0-f44.google.com with SMTP id a12so1646730wgh.11 for <ietf-http-wg@w3.org>; Thu, 25 Apr 2013 11:48:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=C5UWeYNUMmi4QmjDX0coBoiynllAeiT7hxPdGc2e1aU=; b=qnVNJr7O0aod92naeniFJLLWUt69KK5G/Nm13LQUtoE31vkXPFu0v2e7f+JD60rN9Y WbNT7yi8/O9lZ2zhLXbkT7ELREwpSR2uElLP+VAXe4nd2mvF6wAO+X0nLdWWa75dyV09 nXOU1UQTTicNnGibGXbwMEZpgEC26aJKQOrQfxQukcdctHbHMZEbbEM+Oxfg43nnI8sR YoCcMlKcXfx3147XjyCHIj/+kuN+RJCbnNzK8DLoySnVYhfoCQ0i86ExoAx+livqQBby Ixvlcl04H9udXufA62OjWT2QuOTwbFViB5RKZY4dp2xAmRT4qjujGz+2VfMoETeZv5Od 0dCA==
MIME-Version: 1.0
X-Received: by 10.194.109.227 with SMTP id hv3mr13585707wjb.32.1366915701455; Thu, 25 Apr 2013 11:48:21 -0700 (PDT)
Received: by 10.194.33.102 with HTTP; Thu, 25 Apr 2013 11:48:21 -0700 (PDT)
In-Reply-To: <CABP7RbfZO9UqKR+ac5kBCEEZVouz-fW0SLND91WYyBwP_zqSCg@mail.gmail.com>
References: <CABP7RbfbZYAHFztpid-7H6jpMDqGoY6RZFk8MLCbOsjmM1=TZA@mail.gmail.com> <CAA4WUYgOu70+Gvy4kSiN0g5+fD7iDi5uOAK9TORAjb7+57Hcig@mail.gmail.com> <CABP7RbfZO9UqKR+ac5kBCEEZVouz-fW0SLND91WYyBwP_zqSCg@mail.gmail.com>
Date: Thu, 25 Apr 2013 11:48:21 -0700
Message-ID: <CABkgnnVHrKONK5uXFNa8ksApwL2QYVgQ=NAtSMbNziF6oXpGYQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=74.125.82.44; envelope-from=martin.thomson@gmail.com; helo=mail-wg0-f44.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.680, 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: lisa.w3.org 1UVRDr-0005WL-M3 8ed34de85bbf8e7e641d0ab0c14433f6
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Push Promise Issues
Archived-At: <http://www.w3.org/mid/CABkgnnVHrKONK5uXFNa8ksApwL2QYVgQ=NAtSMbNziF6oXpGYQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17568
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>

OK, I have made a few clarifying edits for #1.

On 24 April 2013 11:31, James M Snell <jasnell@gmail.com>; wrote:
> On Wed, Apr 24, 2013 at 10:25 AM, William Chan (陈智昌)
> <willchan@chromium.org>; wrote:
>> 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:
>>>
> [snip]
>>>
>>> 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).
>>
>
> The main reason is that there is a difference between a client no
> longer needing a pushed stream vs. not wanting it at all. For
> instance, if the client navigates away from a page, the stream being
> pushed is CANCELed. If the client returns back to that page later,
> then the server will likely attempt to push the resource again. If,
> however, the client refuses a pushed stream because the pushed
> resource is unacceptable in some manner, then the server might choose
> to not attempt pushing the resource again later on (obviously there
> are quite a few assumptions about managed state being made in that
> example). The bottom line is that I do not think we should make too
> many assumptions about how a server will handle the difference between
> the two cases.

In this case, the distinction between error codes doesn't seem
especially important.  The method is idempotent, so regardless of what
the error code says, it's safe to try again.

The only reason I think that CANCEL makes marginally more sense is
that the server has, at the time of the PUSH_PROMISE, committed to
doing something.  If you model PUSH_PROMISE as "I synthesized this GET
request for you on this other stream", then clearly the stream hasn't
been refused by the server.

>>> 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.
>>
>
> I tend to agree, but it needs to be stated explicitly if this is the
> case. Some simple statement along the lines of: A client can send a
> CANCEL if the server takes too long to send a promised stream... etc
>
> [snip]
>>>
>>> 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.

I'm not going to touch this one.  Open a design issue if you think
this is important.

Actually, as a side note, I think its best to assume that all
unspecified behavior is prohibited.  We'll get around to closing
loopholes eventually, but using something without defined semantics is
inadvisable.