Re: Submitted new I-D: Cache Digests for HTTP/2
Kazuho Oku <kazuhooku@gmail.com> Thu, 14 January 2016 09:00 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C8E1B2D39 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 14 Jan 2016 01:00:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.003
X-Spam-Level:
X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYpxug7oyGQW for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 14 Jan 2016 01:00:05 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915DA1AC3BE for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 14 Jan 2016 01:00:05 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aJdhC-0006t1-2w for ietf-http-wg-dist@listhub.w3.org; Thu, 14 Jan 2016 08:55:54 +0000
Resent-Date: Thu, 14 Jan 2016 08:55:54 +0000
Resent-Message-Id: <E1aJdhC-0006t1-2w@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <kazuhooku@gmail.com>) id 1aJdh7-0006rj-Hz for ietf-http-wg@listhub.w3.org; Thu, 14 Jan 2016 08:55:49 +0000
Received: from mail-wm0-f50.google.com ([74.125.82.50]) by lisa.w3.org with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <kazuhooku@gmail.com>) id 1aJdh0-0001ug-2g for ietf-http-wg@w3.org; Thu, 14 Jan 2016 08:55:46 +0000
Received: by mail-wm0-f50.google.com with SMTP id b14so417248942wmb.1 for <ietf-http-wg@w3.org>; Thu, 14 Jan 2016 00:55:21 -0800 (PST)
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=Xnl/aBha1JG0sBGaQwcJDgzJUMC4/cpiK9eYwDrQXww=; b=0GCL1uaqI8ssqNzZhBGGW/i2d2x7O9cCAQ1527Oc9ZDeq21RAKHKVUHTA133Qyk6kT eNS94S4nATtC4x+GH7tp6kvs9QM5WPju4JrxUaArWCqxVRXi2KHzWskLJrDLPfnHRpA+ mZ67Y2eIi8a9GI6jO6XkA9WyNDAdlzGw5YTm4/uU9vnfqXjkavPy3VRlxdt1LC1kaH9w 5hsgkZGHJluNvutFIHjp6vGK3JawZttzCnP31gUNOGAbeTV0Gsb0O4KYZrLCOVlqwKjk VkY29XYCyKtzIenauIDblLz/xebEkIZZGg+ahpWoRBYhns0blxeOfJIIW7eCar7BLeJo Tu8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Xnl/aBha1JG0sBGaQwcJDgzJUMC4/cpiK9eYwDrQXww=; b=ch/38z6yPetC/qYfvQ6Rp8gBKJG4ftFLArHJxqoJPphCDThWBMWixzpy8269clVUhJ /3trvnezvgsHEsW7M2KiYzN3TIrtBVOpXaRa1QGVODAf/JS3HuaNwLUiBCGIMzX0KYqX Rx/tkWoRm8nbOBLyisjFn5n/D815SEu/QK6MdlAuuiIhs0IBH2bxTfKTAGANYSnauPhj lJP9PgPWG9yN0VAatAkMMClVZI4k7NfLEgPB4oGZQ+9sklyGEQIEWb47+RYxyFJg9tTc TC1RIGE/bSAdNIjoJ9f6nDEq4r3s+Bt9M+V5NpooKUZIairrbxNZ+zqhbGnlxen9D348 oKGQ==
X-Gm-Message-State: ALoCoQk8AvGg6kQ3+9+VMeiB9adcqlsMNx48d2o8XWFi7BiyUjsvIGrX5P7WPeCD6rmZGK3vZMznYjzXhmQW0IrcwMfgJPb28A==
MIME-Version: 1.0
X-Received: by 10.194.172.2 with SMTP id ay2mr2667966wjc.137.1452761715690; Thu, 14 Jan 2016 00:55:15 -0800 (PST)
Received: by 10.194.235.163 with HTTP; Thu, 14 Jan 2016 00:55:15 -0800 (PST)
In-Reply-To: <CAKRe7JHh9maCnBgODU_rr5TFVmy3Tdm2bwEp2hHsONW8e_LTjw@mail.gmail.com>
References: <CAAMqGzYUoCMxBxUEY9wfLOHZp7nrO4d1q5JZo=96pfEbVS1-ew@mail.gmail.com> <652C3E3A-3DA6-40BB-82FF-01A7D65FF65C@lukasa.co.uk> <CABCZv0piAoDnA1J+2pJ3HyF_iRwj9AaFGfonFjdKGfYr=cGZgQ@mail.gmail.com> <CAKRe7JG16u+MteBz4Rz7iCnHxfhLZ=QbWekrhgNhNkq+pKhVAg@mail.gmail.com> <CANatvzyT_ohm5hEcJ1o8B+AEa70607E-LUnPp5cD8sSO8X0HKA@mail.gmail.com> <56958980.1030307@treenet.co.nz> <CANatvzyOnMSLHfXcDrGSjbtZi5nFX2e9_4tHOjmR2OqBWEYUcg@mail.gmail.com> <EDB7D8A6-9121-4268-8920-223E9BE16B19@greenbytes.de> <CAKRe7JHh9maCnBgODU_rr5TFVmy3Tdm2bwEp2hHsONW8e_LTjw@mail.gmail.com>
Date: Thu, 14 Jan 2016 17:55:15 +0900
Message-ID: <CANatvzw6NpbpA_56GbSiCH2yEQoAuaGtXneOvrogBfucqrC8Qw@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
To: Ilya Grigorik <ilya@igvita.com>
Cc: Stefan Eissing <stefan.eissing@greenbytes.de>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=74.125.82.50; envelope-from=kazuhooku@gmail.com; helo=mail-wm0-f50.google.com
X-W3C-Hub-Spam-Status: No, score=-5.5
X-W3C-Hub-Spam-Report: AWL=-0.817, BAYES_00=-1.9, 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, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1aJdh0-0001ug-2g 1f3f7fed896251774746cf759dc34de0
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Submitted new I-D: Cache Digests for HTTP/2
Archived-At: <http://www.w3.org/mid/CANatvzw6NpbpA_56GbSiCH2yEQoAuaGtXneOvrogBfucqrC8Qw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30927
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>
2016-01-14 6:03 GMT+09:00 Ilya Grigorik <ilya@igvita.com>: > > On Wed, Jan 13, 2016 at 1:40 AM, Stefan Eissing > <stefan.eissing@greenbytes.de> wrote: >> >> > To summarize, the draft utilizes the fact that HTTP/2 multiplexes HTTP >> > requests into a single, ordered stream to make things simple. >> > Considering the fact that we need to rely on HTTP/2 to push things >> > anyways (that is the primary target of the draft), I think that is a >> > reasonable trade-off. >> >> There might be use cases to >> a) transport a cache digest over HTTP/1.1 >> b) expose a cache digest to a web application >> >> I think the draft could define a header field for this purpose >> and describe its use. Specifically >> - HTTP/1.1 clients should make it a Connection header >> - HTTP/1.1 to H2 transformers may use it in calculating their >> CACHE_DIGEST frames (depending on their caching strategy) >> - similar for H2 to HTTP/1.1 gateways >> >> So this header, let's call it "Cache-Digest" for the sake of >> discussion, could appear in HTTP/1.1 requests or on web server >> and clients internal APIs: >> >> ... >> Cache-Digest: <base64url encoded, golombset compressed digests> >> Connection: Cache-Digest >> ... >> >> The question is what a H2 origin server does with such a header, >> should it appear. Ignore, discard? >> >> I don't see that the draft should care about H2 header >> compression efficiency of such a beast. Sending it over H2 >> seems more a curiosity to me. I like Stefan's proposal to include a definition of how Cache Digest should be encoded as a header. Defining it will increase the flexibility of how the value can be used. > Agreed. As was highlighted previously, exposing it via a header makes it > accessible to web developers (and removes the requirement for UA to support > this "natively" to get any benefit or use), which (to me, at least) far > outweighs the benefits of saving a few bytes. I understand your points. However, the issue is that the information is hop-by-hop. In terms of HTTP/1, a header specifying the cache digest should be included in the `Connection` header. However, both XMLHttpRequest and Fetch API (IIRC on which ServiceWorker depends) disallows applications to modify the Connection header. So a SW trying to send cache digest needs to send the value without designating it as a hop-by-hop header. And that means that if a H2 origin server sees the header, it needs to determine if the request came through an intermediary, and only use the value if it did not. Or else, a server might end up repeatedly pushing resources to a caching proxy that already has them cached. This looks like a hack to me, and I am not sure if it should be permitted within a specification, even though I believe it would work effectively (as we are doing in H2O). > ig -- Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alex Rousskov
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alex Rousskov
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alex Rousskov
- Re: Submitted new I-D: Cache Digests for HTTP/2 Cory Benfield
- Re: Submitted new I-D: Cache Digests for HTTP/2 Chris Bentzel
- Re: Submitted new I-D: Cache Digests for HTTP/2 Ilya Grigorik
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Amos Jeffries
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Amos Jeffries
- Re: Submitted new I-D: Cache Digests for HTTP/2 Ilya Grigorik
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Cory Benfield
- Re: Submitted new I-D: Cache Digests for HTTP/2 Ilya Grigorik
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Julian Reschke
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Richard Bradbury
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Eliezer Croitoru
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Eliezer Croitoru
- Re: Submitted new I-D: Cache Digests for HTTP/2 Richard Bradbury
- Re: Submitted new I-D: Cache Digests for HTTP/2 Amos Jeffries
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- RE: Submitted new I-D: Cache Digests for HTTP/2 Mike Bishop
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- RE: Submitted new I-D: Cache Digests for HTTP/2 Mike Bishop
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- RE: Submitted new I-D: Cache Digests for HTTP/2 Mike Bishop
- Re: Submitted new I-D: Cache Digests for HTTP/2 Patrick McManus
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E