Re: [#153] PUSH_PROMISE headers
Roberto Peon <grmocg@gmail.com> Sat, 29 June 2013 05:55 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 A3EAB21F9E7E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 28 Jun 2013 22:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 b1agtjHOwU1G for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 28 Jun 2013 22:55:22 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1B92A21F9E6D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 28 Jun 2013 22:55:21 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Uso7L-0005Dt-KF for ietf-http-wg-dist@listhub.w3.org; Sat, 29 Jun 2013 05:54:39 +0000
Resent-Date: Sat, 29 Jun 2013 05:54:39 +0000
Resent-Message-Id: <E1Uso7L-0005Dt-KF@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1Uso77-0005BA-1m for ietf-http-wg@listhub.w3.org; Sat, 29 Jun 2013 05:54:25 +0000
Received: from mail-oa0-f42.google.com ([209.85.219.42]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1Uso75-00018G-N4 for ietf-http-wg@w3.org; Sat, 29 Jun 2013 05:54:25 +0000
Received: by mail-oa0-f42.google.com with SMTP id j6so3176832oag.15 for <ietf-http-wg@w3.org>; Fri, 28 Jun 2013 22:53:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uGfZIps+QP9yZ1kKLfviMRZdP6lOilFPkOkwyf+dSK8=; b=f8pGZjc+VpaTFNatg1MHxbEB7UI22tx6ysFu4hKJj6OCNKvhVvZ3vhebpsKi9VEzP0 d2/yGKWFIZAIdXsI4UiG4dLTnY4m7izkFPdfxaem4LcN8Byd9kn0k+H5hc33w1d7IYq9 CP7+qRFpM0+2nyPj7VG0408qy64Nd1mbz6+s2F2YZrbChio2A0sakznbV2n1v6Ujz1Xt XpMLho0jsZl/qHdr0f1Py+YZdQfL2TCMxMqeGWDMudsq5mvJzrGe+kV935WRtQvdNodF qeAjLnhR0MktlBcoPf0uKMRw8MndqrAvBUpoN+TTGD+wRnu0UJZs4f0fLQ0CXTGTODpY X90w==
MIME-Version: 1.0
X-Received: by 10.60.55.196 with SMTP id u4mr6410168oep.57.1372485237790; Fri, 28 Jun 2013 22:53:57 -0700 (PDT)
Received: by 10.76.71.10 with HTTP; Fri, 28 Jun 2013 22:53:57 -0700 (PDT)
In-Reply-To: <CABP7RbdoBswznxwDm+-00egSHV+h7fO7Ow+aw+mFhLm2Z=GRWg@mail.gmail.com>
References: <CABkgnnVGh9dLkfDrO2fq5TsnxwEu0Dff=LqJEJR5Odq2ibfDMg@mail.gmail.com> <CABP7RbcoSSSKJq3YbZ2ypw-xb0uOgFQcjcQP9tJdkgEjPfJVMA@mail.gmail.com> <CAP+FsNdJcZ_x6RidaVfP+VPtA3CwAbALgAqhOhAjZLzaz4tQRQ@mail.gmail.com> <CABP7Rbf_pGKU-yB-f=6fB5WoVvs087eOf6Beo4DDHGJWYX5XTQ@mail.gmail.com> <CAP+FsNd9BDHBO2YXEfHwvRuiJDDpbAEvCMR2BKLzcoaARxjDJA@mail.gmail.com> <CAP+FsNcEf6s5s7Jk=NLKdrdU8fV1AsSJ4u-8CZNT8P7YXvxkag@mail.gmail.com> <CABP7RbdoBswznxwDm+-00egSHV+h7fO7Ow+aw+mFhLm2Z=GRWg@mail.gmail.com>
Date: Fri, 28 Jun 2013 22:53:57 -0700
Message-ID: <CAP+FsNf-m8toh_KNN0dinwCvP_+2JBKq8OWrany2sHM+c2js3A@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="089e012292ac0edc5a04e0449f1e"
Received-SPF: pass client-ip=209.85.219.42; envelope-from=grmocg@gmail.com; helo=mail-oa0-f42.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.667, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1Uso75-00018G-N4 c2ca34b2ae2aa16b929ff81571cd0e34
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [#153] PUSH_PROMISE headers
Archived-At: <http://www.w3.org/mid/CAP+FsNf-m8toh_KNN0dinwCvP_+2JBKq8OWrany2sHM+c2js3A@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18413
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>
Actually, I think you're right, since the resource is identified by the URL name (unfortunate in some ways). I was thinking that you'd want to indicate both the canonical name for the served resource and the name used to identify the request, but that'd be a bigger change. -=R On Fri, Jun 28, 2013 at 10:44 PM, James M Snell <jasnell@gmail.com> wrote: > I just gave an example that uses content-negotiation so that argument > doesn't really work. The server is crafting the request headers for an > implied GET, so it gets to construct those request headers to be as > specific as it wants them to be, without much need for actual > content-negotiation. > > For example, suppose the server receives a request for an HTML page like > this... > > GET /index.html HTTP/1.1 > Accept: text/html, image/jpeg, image/gif > > The server decides that it wants to push jpeg files to the client... it > sends > > PUSH_PROMISE > :path = /images/f.jpg > :method = GET > :host: example.org > :if-match: "my-etag1" > accept: image/jpeg > > That's pretty darn unambiguous. I can easily check to see if I have a > representation of "/images/f.jpg" with etag "my-etag1" and > content-type "image/jpeg" in my local cache, without the need to have > *any* response headers in the PUSH_PROMISE. > > Perhaps you have another, more specific example in mind? > > > On Fri, Jun 28, 2013 at 10:36 PM, Roberto Peon <grmocg@gmail.com> wrote: > > ... because by then you've opened up a stream., and you're back into > > problematic territorry. > > PUSH_PROMISE exists because we need to indicate to the browser all of the > > information it needs to make a determination about whether or not it > wants > > the stream (and to short circuit the inlining/push mechanism when it > already > > has what it needs!) > > -=R > > > > > > On Fri, Jun 28, 2013 at 10:34 PM, Roberto Peon <grmocg@gmail.com> wrote: > >> > >> Any content negotiation would be an appropriate example. :) > >> > >> You don't want to have to wait for the HEADERS frame to indicate to the > >> client which resource it might already have (it should have the > opportunity > >> to RST_STREAM if it has it in cache, for instance). > >> -=R > >> > >> > >> On Fri, Jun 28, 2013 at 10:25 PM, James M Snell <jasnell@gmail.com> > wrote: > >>> > >>> Have an example handy? > >>> > >>> Here's an example that shows that response headers in the PUSH_PROMISE > >>> would not be necessary... Let's say I send a PUSH_PROMISE with the > >>> following bits of info... > >>> > >>> PUSH_PROMISE > >>> :path = /images/f.jpg > >>> :method = GET > >>> :host = example.org > >>> :scheme = http > >>> accept = image/jpeg > >>> if-match: "my-etag1" > >>> cache-control: max-age=1000 > >>> > >>> These headers are giving me everything I would need to determine if > >>> there is a matching resource in my local cache. I have the method, I > >>> have the etag, I have the cache-control parameters, accept... There's > >>> no need for response headers at this point. > >>> > >>> Later, once I start accepting the frames for the pushed content, I > >>> would get something like... > >>> > >>> HEADERS > >>> :status = 200 > >>> content-type: image/jpeg > >>> content-length: 123 > >>> etag: "my-etag1" > >>> vary: accept > >>> cache-control: public > >>> > >>> On the off chance that the PUSH_PROMISE doesn't give me what I need, > >>> the follow on HEADERS frame will give me the rest. > >>> > >>> > >>> > >>> On Fri, Jun 28, 2013 at 9:55 PM, Roberto Peon <grmocg@gmail.com> > wrote: > >>> > Depending on how the request might have been been constructed, > response > >>> > headers may be necessary to identify the resource in the cache, as > >>> > compared > >>> > to the resource specified in the HTML (I'm thinking about vary: > stuff). > >>> > > >>> > -=R > >>> > > >>> > > >>> > On Fri, Jun 28, 2013 at 9:44 PM, James M Snell <jasnell@gmail.com> > >>> > wrote: > >>> >> > >>> >> Let's take a step back and consider what a pushed stream is... > >>> >> > >>> >> A pushed stream is essentially an "Implied GET". This means that a > >>> >> server is going to assume that the client was going to send a GET > for > >>> >> the pushed resource. This also means that the server has to make > some > >>> >> assumptions about the make up of that implied GET. > >>> >> > >>> >> Now, consider how HTTP caching works. When a cache receives a > request > >>> >> for a resource, how does it determine whether or not it has a > >>> >> representation of the resource already available? Does it look at > the > >>> >> request headers or the response headers? Obviously, it looks at the > >>> >> request headers. It uses the response headers when populating the > >>> >> cache. > >>> >> > >>> >> So, if we look at the pushed resource sent by the server, what we > need > >>> >> is for A) the server to first let us know about the implied GET > >>> >> request.. which means pushing down a set of request headers then B) > >>> >> the server to send the actual resource, which means pushing down the > >>> >> response headers. > >>> >> > >>> >> Already in our design for pushed resources, we have the server > sending > >>> >> a PUSH_PROMISE frame that contains a header block, followed by a > >>> >> HEADERS frame that also contains a headers block. It stands to > reason > >>> >> that the PUSH_PROMISE frame would contain the set of request headers > >>> >> that the server is assuming for the implied GET. These are delivered > >>> >> to the client, which uses those to determine whether or not a cached > >>> >> representation of the resource is already available (just as any > cache > >>> >> would do using the request headers). The server would then send it's > >>> >> response headers in a HEADERS frame, just as it would any response > to > >>> >> any other kind of GET. > >>> >> > >>> >> Two examples to show how this naturally fits... First, let's look > at a > >>> >> normal GET request sent by the client to the server... > >>> >> > >>> >> Client Server > >>> >> ------ ------ > >>> >> | | > >>> >> | ---------------------> | > >>> >> | HEADERS | > >>> >> | GET | > >>> >> | /images/f.jpg | > >>> >> | If-Match: etag1 | > >>> >> | Accept: image/jpeg | > >>> >> | | > >>> >> | <--------------------- | > >>> >> | HEADERS | > >>> >> | 200 | > >>> >> | Content-Type: | > >>> >> | image/jpeg | > >>> >> | Content-Length: | > >>> >> | 123 | > >>> >> | | > >>> >> | <--------------------- | > >>> >> | DATA....DATA.... | > >>> >> | | > >>> >> > >>> >> Now consider the same resource being pushed by the server using > >>> >> PUSH_PROMISE... > >>> >> > >>> >> Client Server > >>> >> ------ ------ > >>> >> | | > >>> >> | <--------------------- | > >>> >> | PUSH_PROMISE | > >>> >> | GET | > >>> >> | /images/f.jpg | > >>> >> | If-Match: etag1 | > >>> >> | Accept: image/jpeg | > >>> >> | | > >>> >> | <--------------------- | > >>> >> | HEADERS | > >>> >> | 200 | > >>> >> | Content-Type: | > >>> >> | image/jpeg | > >>> >> | Content-Length: | > >>> >> | 123 | > >>> >> | | > >>> >> | <--------------------- | > >>> >> | DATA....DATA.... | > >>> >> | | > >>> >> > >>> >> > >>> >> Note that the only difference here is the direction and type of the > >>> >> first frame. Everything else is identical. The PUSH_PROMISE contains > >>> >> everything the client needs to determine whether or not it already > has > >>> >> the resource in it's local cache (request URI, etag, > content-type...). > >>> >> > >>> >> There's no need to get any more complicated than this. We already > >>> >> require two distinct header blocks for every request. We already > send > >>> >> two distinct header blocks for each pushed stream. We already > indicate > >>> >> that a pushed stream is an implied GET. To make it work, we simply > >>> >> state that the PUSH_PROMISE contains the Request headers that the > >>> >> server has assumed for the implied GET request, while the HEADERS > >>> >> frame sent later contains the Response headers. If the request > headers > >>> >> in the PUSH_PROMISE end up not being adequate enough to properly > >>> >> determine if the resource is already cached, then we treat it as > just > >>> >> another cache miss. > >>> >> > >>> >> On Fri, Jun 28, 2013 at 5:21 PM, Martin Thomson > >>> >> <martin.thomson@gmail.com> wrote: > >>> >> > https://github.com/http2/http2-spec/issues/153 > >>> >> > > >>> >> > The current text describes PUSH_PROMISE as having a few request > >>> >> > headers, plus some response headers, but it's quite vague. > >>> >> > > >>> >> > I think that if this is going to be properly workable across a > wide > >>> >> > range of uses with lots of different headers, PUSH_PROMISE needs > to > >>> >> > include two sets of headers: the ones that it overrides from the > >>> >> > associated request (:path being foremost of those) and the ones > that > >>> >> > it provides as a "preview" of the response (e.g., ETag might allow > >>> >> > caches to determine if they were interested in the rest of the > >>> >> > response). > >>> >> > > >>> >> > >>> > > >> > >> > > >
- [#153] PUSH_PROMISE headers Martin Thomson
- Re: [#153] PUSH_PROMISE headers James M Snell
- Re: [#153] PUSH_PROMISE headers Roberto Peon
- Re: [#153] PUSH_PROMISE headers James M Snell
- Re: [#153] PUSH_PROMISE headers Roberto Peon
- Re: [#153] PUSH_PROMISE headers Roberto Peon
- Re: [#153] PUSH_PROMISE headers James M Snell
- Re: [#153] PUSH_PROMISE headers Roberto Peon
- Re: [#153] PUSH_PROMISE headers David Morris
- Re: [#153] PUSH_PROMISE headers Amos Jeffries
- Re: [#153] PUSH_PROMISE headers Yoav Nir
- Re: [#153] PUSH_PROMISE headers James M Snell
- Re: [#153] PUSH_PROMISE headers Jeff Pinner
- Re: [#153] PUSH_PROMISE headers Michael Sweet
- Re: [#153] PUSH_PROMISE headers David Morris
- Re: [#153] PUSH_PROMISE headers Amos Jeffries
- Re: [#153] PUSH_PROMISE headers Martin Thomson
- RE: [#153] PUSH_PROMISE headers Mike Bishop
- Re: [#153] PUSH_PROMISE headers Martin Thomson
- Re: [#153] PUSH_PROMISE headers James M Snell
- Re: [#153] PUSH_PROMISE headers Martin Thomson
- Re: [#153] PUSH_PROMISE headers Sam Pullara
- Re: [#153] PUSH_PROMISE headers Martin Thomson
- RE: [#153] PUSH_PROMISE headers Mike Bishop
- Re: [#153] PUSH_PROMISE headers James M Snell
- RE: [#153] PUSH_PROMISE headers Mike Bishop
- Re: [#153] PUSH_PROMISE headers Roberto Peon
- Re: [#153] PUSH_PROMISE headers Amos Jeffries
- Re: [#153] PUSH_PROMISE headers Roberto Peon
- Re: [#153] PUSH_PROMISE headers William Chan (ιζΊζ)