Re: Push Promise Issues

William Chan (陈智昌) <willchan@chromium.org> Fri, 26 April 2013 02:14 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 A8A9421F973B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 25 Apr 2013 19:14:09 -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 gWWIsa2Rea+4 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 25 Apr 2013 19:14:08 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 34B3E21F973A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 25 Apr 2013 19:14:07 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UVYAa-0004EE-D8 for ietf-http-wg-dist@listhub.w3.org; Fri, 26 Apr 2013 02:13:52 +0000
Resent-Date: Fri, 26 Apr 2013 02:13:52 +0000
Resent-Message-Id: <E1UVYAa-0004EE-D8@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <willchan@google.com>) id 1UVYAU-0004Ba-9Q for ietf-http-wg@listhub.w3.org; Fri, 26 Apr 2013 02:13:46 +0000
Received: from mail-qa0-f41.google.com ([209.85.216.41]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UVYAT-0004zR-4b for ietf-http-wg@w3.org; Fri, 26 Apr 2013 02:13:46 +0000
Received: by mail-qa0-f41.google.com with SMTP id hg5so47538qab.0 for <ietf-http-wg@w3.org>; Thu, 25 Apr 2013 19:13:19 -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=sWhxHhP0hKSpCQNgxEf2wYyuLahYEV2d9doVdWMv3ak=; b=OkGrcLGH5Vm2wiVr2xo/hH4zmRhBR1LJ86ae6YplJi3xODU5cv5K5hQvj0OcoaFZP/ z/N5IJYT2TnvOyHE5Ozfdf/KMZi3c2vDU3O0Yffq6lB/g4UZTTaUeSHtnem/JzYkM3dt LyyKi03o9uxHeyMaFqPMrn4P3/OybQCMLM3MRoc052LYvvf5CiDGyKOzwbSTGEpiOj5N GMZo914WFqdNwNrI3xXUryXurw+QaQlbVdtkiI6chLgzPkyqDrQZdQlk/Cff4mLH5Fc4 EUR62RJsuSi8UE2HWW2eMRTah//HnLQGDUkNpHqJlPULeh+cQdZWyz2+xB/CpbldSJLL AEkA==
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=sWhxHhP0hKSpCQNgxEf2wYyuLahYEV2d9doVdWMv3ak=; b=OmH8alNPpn7lsgNr5EtCKhTvt2tkY2OFjHoWEbw6QtIlGmEuO07yCugkazjxUh35bd 7AvedeuTZ385xaJoDLPA8kqrnQ6az8C3n0VkVb5o9V0Sl2UUYcJ41LS6X4/hx1lps1Ic LqP9UY4U0JWrLSRElJBEu3Lp2qFFAZDnwWf18=
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=sWhxHhP0hKSpCQNgxEf2wYyuLahYEV2d9doVdWMv3ak=; b=ACZfLouTW24gUzbTWLpVFSnqrHiQSiORNJMu28KpSQWW++n1JfAvFC5ozhD7ORx1mF Ie44mKWt8+wUC34pXgtyX1qzG0HitSD4wBiNxjNBW4zkU1nYhp0qgjk+EaQE9QpqPU9j e10T5QJJltoeudsAm4pqFvp4pTeyIN8nVDlXRxpMySRoCDw9jVKJA47uHVGxQlcGPLre vjXatI8fTH59BpuJvCVO+Z03zIss1arTCR+8K5IkP82VvPFtD9aJr3lv3z5oGAQcbG7x drDrx6c/cHmn0nP/X4oLUjtHunfGo5UlI86ju5FRkl5MeETyBkdc9MRaXkfE0ZoswR6l /TPw==
MIME-Version: 1.0
X-Received: by 10.224.65.1 with SMTP id g1mr12451323qai.64.1366942399407; Thu, 25 Apr 2013 19:13:19 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.180.4 with HTTP; Thu, 25 Apr 2013 19:13:19 -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 19:13:19 -0700
X-Google-Sender-Auth: 0i_Vs8Z9ca5uUnRZNBVQsW2etTM
Message-ID: <CAA4WUYj17sw5Nd-8OHNVzvK312zP76kXO==X3kYBb4isjGps-g@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=001a11c2d96e25422204db3a1479
X-Gm-Message-State: ALoCoQm10h2CixFz94XIozcuiTIC9MoeCzic9MLrOQ17hYW4TcjuM0OaatXTmYYTGZYPMWQWrus1zyCW+1Kd8jeJAfmPze8qHWcCBaDb3ZGUUgDUKJY3MoDSZpE1c19DIo9eD1RfizlapPr/oKCzo8vuy+/YrSM+pmksE/GLKbBSG4aL0kGZxy/p1Pd6/R7/Y39LZKQjjSO4
Received-SPF: pass client-ip=209.85.216.41; envelope-from=willchan@google.com; helo=mail-qa0-f41.google.com
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.747, BAYES_00=-1.9, 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: maggie.w3.org 1UVYAT-0004zR-4b 70d9fb37b65cc429410c79359f1193f7
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Push Promise Issues
Archived-At: <http://www.w3.org/mid/CAA4WUYj17sw5Nd-8OHNVzvK312zP76kXO==X3kYBb4isjGps-g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17593
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>

On Wed, Apr 24, 2013 at 11:31 AM, 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.
>
> >>
> >>
> >> 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.
> >>
> >>
> >> 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.
> >
>
> The idea is simply sending multiple request payloads with a single
> http operation.. a POST with N-number individual associated streams,
> for instance. Uploading photos is one use case, adding items to an
> Atom Publishing Collection is another. Right now much of this is done
> using clunky multipart mime formats. It could be done more efficiently
> with multiplexed streams.
>

I don't understand this. Go ahead and use multiple HTTP POSTs with multiple
streams. Why do you need a client initiated PUSH_PROMISE for that?


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