Re: More cache control for (X)HTML pages

Mark Nottingham <mnot@mnot.net> Fri, 04 January 2013 22:47 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912F821F8812 for <ietf@ietfa.amsl.com>; Fri, 4 Jan 2013 14:47:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EHmRQE16G46 for <ietf@ietfa.amsl.com>; Fri, 4 Jan 2013 14:47:33 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 73F5E21F8815 for <ietf@ietf.org>; Fri, 4 Jan 2013 14:47:33 -0800 (PST)
Received: from [192.168.1.80] (unknown [118.209.230.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CBC8C509BA; Fri, 4 Jan 2013 17:47:31 -0500 (EST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: More cache control for (X)HTML pages
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAMVzVHMeO6G6bxZ2qe6GVPVFEDJEeJXoAxMFTmmChaSQt89DWQ@mail.gmail.com>
Date: Sat, 05 Jan 2013 09:47:26 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5D756BE9-8597-41C9-B268-1AA10022DB11@mnot.net>
References: <CAMVzVHMeO6G6bxZ2qe6GVPVFEDJEeJXoAxMFTmmChaSQt89DWQ@mail.gmail.com>
To: Nathan <thegreatall@gmail.com>
X-Mailer: Apple Mail (2.1499)
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jan 2013 22:47:34 -0000

Hi Nathan,

Have you looked at the HTML5 AppCache? It operates in a manner similar to what you're describing.

http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html

That said, most people seem to agree that AppCache is somewhat problematic; although some do use it, it's fairly fussy to work with, and adoption hasn't been wide. Also, note that it creates a cache that's separate to the "normal" HTTP cache.

If you want to propose this particular mechanism, I'd recommend talking to the WHAT WG <http://www.whatwg.org/> and making sure that the HTTPBIS WG <http://trac.tools.ietf.org/wg/httpbis/trac/wiki> is looped in; because it involves both HTML and HTTP caching, it touches both. However, I'd observe that what you're *really* trying to do is to overcome the limitations of HTTP's current use of TCP, and that's what we're trying to do with HTTP2 in HTTPBIS; if you wait a bit, this shouldn't be necessary.

Regards,


On 05/01/2013, at 9:18 AM, Nathan <thegreatall@gmail.com> wrote:

> Hi, this is my first post so forgive me if I posted in the wrong spot.
> 
> I am contemplating writing an RFC on an HTML tag to be placed in the <head> of a webpage which gives the browser instructions on a single location were the page may obtain bulk cache information from the server instead of having each time a new cache-able element is requested having the browser create a new http request to the server to only have the server respond with a 304 Not Modified.
> 
> I am not going into detail but a quick over view would look something like (taken from google.com homepage's cache-able files):
> <head>
>     ...
>     <cache src="/script-to-handle-bulk-cache-checking">
>         <file href="images/srpr/logo3w.png" />
>         <file href="xjs/_/js/s/c,sb,cr,vm,cdos,jsa,sf,tbpr,tbui,rsn,ob,mb,lc,hv,cfm,klc,kat,aut,esp,erh,bihu,amcl,kp,lu,m,rtis,shb,sfa,hsm,j,p,pcc,csi/rt=j/ver=K-W_gw26Qd4.en_US./d=1/sv=1/rs=AItRSTP1F4RezC8aHlgXoNQaBhX3N9n9sQ" />
>         <file href="extern_chrome/edf8435073bcf94.js" />
>         <file href="xjs/_/js/s/sy10,gf,sy45,sy46,sy81,sy44,sy39,sy82,sy8,sy34,sy50,sy48,sy80,sy99,sy105,sy108,sy9,sy15,mbtt,ssi,ifl/rt=j/ver=K-W_gw26Qd4.en_US./d=0/sv=1/rs=AItRSTP1F4RezC8aHlgXoNQaBhX3N9n9sQ" />
>         <file href="textinputassistant/tia.png" />
>         <file href="images/nav_logo114.png" />
>     </cache>
>     ...
> </head>
> 
> The browser would then block until it cross references it's own cache with the listed files and (if > 1) send a request to the location specified in the "src" attribute in the "cache" tag with the cross referenced files list and the associated "if-modified-since" date of each file. The server would then respond telling the browser to use the cache for the files that can be used for cache. Any other files need to be loaded load like normal.
> 
> The idea would be to have a page with many images, javascript, css, exc... to do a single request in the hopes that the it could save any of those cache-able files from needing their own request to the server to see if they have been modified.
> 
> If there is already an RFC for this a link to it would be appreciated as I looked for one and came up with only http header cache controls which does not work the same way.
> 
> Thank you,
> -Nathan Bruer

--
Mark Nottingham   http://www.mnot.net/