IETF Logo Mail Archive

Re: Submitted new I-D: Cache Digests for HTTP/2

Kazuho Oku <kazuhooku@gmail.com> Wed, 27 January 2016 04:42 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 6D3761AC3EE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 26 Jan 2016 20:42:28 -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 28e5rnmwVyMB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 26 Jan 2016 20:42:26 -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 5B9401AC3CF for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 26 Jan 2016 20:42:26 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aOHsp-0007nL-IX for ietf-http-wg-dist@listhub.w3.org; Wed, 27 Jan 2016 04:39:07 +0000
Resent-Date: Wed, 27 Jan 2016 04:39:07 +0000
Resent-Message-Id: <E1aOHsp-0007nL-IX@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 1aOHsk-0007ma-Nz for ietf-http-wg@listhub.w3.org; Wed, 27 Jan 2016 04:39:02 +0000
Received: from mail-wm0-f53.google.com ([74.125.82.53]) by lisa.w3.org with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <kazuhooku@gmail.com>) id 1aOHsi-0002ac-Iu for ietf-http-wg@w3.org; Wed, 27 Jan 2016 04:39:01 +0000
Received: by mail-wm0-f53.google.com with SMTP id l65so130030483wmf.1 for <ietf-http-wg@w3.org>; Tue, 26 Jan 2016 20:38:40 -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=4P5OXNEGs1a29yla5DbhUNR0KKdZTWKCjIaibDKFRJQ=; b=DVOUyrxsfy+xkVyorEenbnZlpayzlfHKr2I66KhBonIJmlyHUGEOT0lykmTTybkSTS aH5LXOkqwiYIF+/jQJDUsr6jxcsv6BeDrt2Y6iYsw7QqxN4dAka+AWVIlTsLJCdncPQf 7n0wBf2uKEJes77bx1gvsDKBfnje0KY1XSAlQ3HxjHwA5cScHLLBvLAxeI9Y4HRJVreh aq5IHqqSBb419UZJJPi8aRzfGQao5+s3+XIkH39H9NO+A+mG6/FZvjoBro4Vl1f70Nsi yzSsFfDSZhXWnzYOsERUHAFnXnkyss/UFuPc7XuRj86/YL8ClGS5vFk197Vyq6nmmRib OvnQ==
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=4P5OXNEGs1a29yla5DbhUNR0KKdZTWKCjIaibDKFRJQ=; b=bTZw8tyagRltMedPywy8YmEKkhiFEUEODLINyLd9CHBTsuIlKw6aKriFfs3qe+N7ue qRcyoafvLg/IfiVM1ARPS1/1BtNGP/lVhuUmcpR2XeRiY8KUeXicdUD3y0M/N1DE/glo +6x7U8t0KDUmwzDIkaK8CMYRFpl5r7bgxTOlujhzAYRgwXwCkc8dOBAqbtcEnsvX8V2P M42uK7n5qrKsxGiNhf4lPlPcf1UJhnCosc7LZy1C8pXeY6Fa0XjSzRnlp2d9G8umcUoy qUPSEuXbwunJh4pVrcqM7hHrlBvycf1GzWu26Vz7nddYDm3xxXYpyq9LCy2w58Ba+B2X OiVA==
X-Gm-Message-State: AG10YOSHIEUwSVzCmpaoUAjpfNlAGvEvVRN1e14/QZI9K1MOJj8sFHVbtybQ+0sqvTJtm1cZcGCZiCIzLwy0Hw==
MIME-Version: 1.0
X-Received: by 10.28.23.73 with SMTP id 70mr26524906wmx.37.1453869514165; Tue, 26 Jan 2016 20:38:34 -0800 (PST)
Received: by 10.194.235.163 with HTTP; Tue, 26 Jan 2016 20:38:33 -0800 (PST)
In-Reply-To: <56A26B1E.4050303@rd.bbc.co.uk>
References: <CANatvzxcKS46iAqAdfBHuWPt5k3XkR79NDMPPtDakOb2jPAywA@mail.gmail.com> <56A26B1E.4050303@rd.bbc.co.uk>
Date: Wed, 27 Jan 2016 13:38:33 +0900
Message-ID: <CANatvzyHbyrK7cjh+JsRpTR42knc6LXX7GWzj8ZEYPgv8cs49g@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
To: Richard Bradbury <richard.bradbury@rd.bbc.co.uk>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Alcides Viamontes E <alcidesv@zunzun.se>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=74.125.82.53; envelope-from=kazuhooku@gmail.com; helo=mail-wm0-f53.google.com
X-W3C-Hub-Spam-Status: No, score=-5.4
X-W3C-Hub-Spam-Report: AWL=-0.736, 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 1aOHsi-0002ac-Iu f3d0c9ff563a8c464a7cce1a38cdb8de
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/CANatvzyHbyrK7cjh+JsRpTR42knc6LXX7GWzj8ZEYPgv8cs49g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31007
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-23 2:47 GMT+09:00 Richard Bradbury <richard.bradbury@rd.bbc.co.uk>:
> Hello. The general thrust of this I-D seems like a useful optimisation of
> HTTP/2 server push. It is wasteful to push a representation to a client when
> the client already has a fresh copy cached. But the reverse is equally true,
> I think...
>
> I therefore support the idea of including version information in the
> client-generated cache digest.

Thank you for your feedback.  I am very happy to see interest in
including the version information in cache digest.

>  This would allow a server to push a more
> up-to-date version of a representation in the case where that representation
> has been updated before the originally stated expiry. This allows a server
> to supply the freshest possible version, overriding the client's (in this
> case mistaken) belief that its cached copy is still fresh.
>
> You suggest below that a client would ignore such a push because it still
> believes its copy to be fresh, thereby defeating the server's attempt to
> push a fresher version.

Actually I had thought the same.

However, my current understanding is that Firefox behaves like that
(i.e. ignore the pushed resources if a fresh entry already existed in
cache), and from what I heard such behavior conforms to the HTTP/2
specification.

> The next question concerns syntax. Elsewhere in the thread I think it has
> been suggested that there could be two types of digest transmitted from
> client to server: one ("fresh") generated from URLs the client believes to
> be fresh, the other ("if-modified-since") based on URLs that it believes to
> be stale. Reading between the lines, am I right in thinking that the latter
> is intended to be a sort of conditional client request, with a "304 Not
> modified" response being pushed in response for those representations that
> turn out not to be stale?

Yes.

> This all seems quite complicated, and I find the combination of parameter
> name and semantics a bit confusing. For simplicity's sake I might be
> inclined to just include the versioning information as standard in all cache
> digests, in spite of the resulting overhead. Then the server can decide what
> needs to be pushed in response after comparing the versioning metadata in
> the received digest with the (potentially more up-to-date) information
> available to the server. And, as an added bonus, you then don't need to
> worry about defining what a pushed 304 response means :-)

For stale entries, I believe that we should always push a response
(which would either be a full response or a 304).  Otherwise, the
client will issue a conditional request, and until the response for
the conditional request becomes available, it may not be able to
render the webpage (if the requested resource was blocking the
critical rendering path).

For fresh entries, we do not need to push a response.

Considering the fact that downstream bandwidth in the first few
packets is precious due to slow-start, I think sending separate
digests for fresh and stale resources is a better approach, since with
the knowledge the server can avoid sending 304 for fresh resources.

> On Tue, 12 Jan 2016 10:04:00 +0900 Kazuho Oku <kazuhooku@gmail.com> wrote:
>
> 2016-01-11 2:11 GMT+09:00 Alcides Viamontes E <alcidesv@zunzun.se>:
>> ...
>> Here are the issues that I see:
>>
>> 1.- In its current wording, no information about which version of a
>> representation the browser already has is present in the cache digest.
>> That information can be included in the URL itself (cache busting),
>> but then it becomes a concern for web-developers, adds complexity to
>> their work, and bypasses the mechanisms that HTTP has in place for
>> maintaining cache state.  It also increases space pressure in the the
>> browser's cache as the server is left with no means to expire old
>> cached contents in the browser.
>
> That is a very good point.
>
> Let me first discuss the restrictions of the cache model used by HTTP,
> and then go on to discuss what we should do if we are to fix the point
> you raised.
>
> First about the restriction; the resources in the cache can be divided
> into two groups: fresh and non-fresh.  A server should never push a
> resource that is considered as fresh in the client's cache.  Clients
> will not notice the push / the HTTP/2 allows client to discard such
> push.  Therefore, a CACHE_DIGEST frame
> must include a filter that marks the resources that are marked as
> being fresh.  That is what the current draft specifies.
>
>
> I think this is a reference to the sentence at the start of Section 2.1
> stating: "The set of URLs that is used to compute Digest-Value MUST only
> include URLs that share origins [RFC6454] with the stream that CACHE_DIGEST
> is sent on, and they MUST be fresh [RFC7234]." In other words, according to
> draft 00, the client-generated digest only includes the URLs of cached
> representations it considers to be fresh.
>
> Next about the point of including version information (e.g.
> Last-Modified, ETag) in the cache digest.  I believe we can add a
> second Golomb-coded set to the frame that uses hash(URI + version
> information) as the key.  A server can refer to the information to
> determine whether if it should push a 304 response or a 200 response.
>
> The downside is that the CACHE_DIGEST frame may become larger (if the
> server sends many responses that would become non-fresh), so it might
> be sensible to allow the client to decide if it should send the second
> Golomb-coded set.
>
> In addition, we should agree on how to push 304 response.  My
> understanding is that HTTP/2 spec., is vague on this, and that there
> has not yet been an agreement between the client developers on how it
> should be done.
>
> Once that is solved, I think we should update the I-D to cover the
> version information as well.
>
>
> Kind regards,
>
> --
> Richard.



-- 
Kazuho Oku

v2.23.0 | Report a Bug | By Email