Re: [codesprints] Who knows about web browser caching?

Bill Fenner <fenner@fenron.net> Sun, 07 November 2010 11:35 UTC

Return-Path: <fenner@fenron.com>
X-Original-To: codesprints@core3.amsl.com
Delivered-To: codesprints@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 725933A696A for <codesprints@core3.amsl.com>; Sun, 7 Nov 2010 03:35:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.676
X-Spam-Level:
X-Spam-Status: No, score=-101.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjwaeQ1k58mX for <codesprints@core3.amsl.com>; Sun, 7 Nov 2010 03:35:35 -0800 (PST)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id D71053A69B6 for <codesprints@ietf.org>; Sun, 7 Nov 2010 03:35:34 -0800 (PST)
Received: by wyb28 with SMTP id 28so4555920wyb.31 for <codesprints@ietf.org>; Sun, 07 Nov 2010 03:35:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.141.14 with SMTP id f14mr3145933wej.22.1289129751949; Sun, 07 Nov 2010 03:35:51 -0800 (PST)
Sender: fenner@fenron.com
Received: by 10.216.230.74 with HTTP; Sun, 7 Nov 2010 03:35:51 -0800 (PST)
In-Reply-To: <4CD68217.2040909@gmx.de>
References: <AANLkTinVeLeso2vttskPjTmeyqyzkFAB+KmeincJAN2m@mail.gmail.com> <4CD667B7.7050609@gmx.de> <71E9318F-4E51-4DCE-8E20-374028FFA283@fenron.net> <4CD68217.2040909@gmx.de>
Date: Sun, 07 Nov 2010 19:35:51 +0800
X-Google-Sender-Auth: BTLKvcGTGU_aWrmlm8r1mlLNx8Y
Message-ID: <AANLkTikFEEU8m=axOjSTs8BHpvo+L+D5n57gBojHQ2mH@mail.gmail.com>
From: Bill Fenner <fenner@fenron.net>
To: Julian Reschke <julian.reschke@gmx.de>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "codesprints@ietf.org" <codesprints@ietf.org>
Subject: Re: [codesprints] Who knows about web browser caching?
X-BeenThere: codesprints@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "List for coordinating \(and following up on\) codesprint activities" <codesprints.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/codesprints>, <mailto:codesprints-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codesprints>
List-Post: <mailto:codesprints@ietf.org>
List-Help: <mailto:codesprints-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codesprints>, <mailto:codesprints-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Nov 2010 11:35:38 -0000

On Sun, Nov 7, 2010 at 6:40 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 07.11.2010 11:17, Bill Fenner wrote:
>>
>> On Nov 7, 2010, at 4:47 PM, Julian Reschke<julian.reschke@gmx.de>  wrote:
>>
>>> Bill,
>>>
>>> you may want to test with redbot, see
>>>
>>>
>>> <http://redbot.org/?uri=http://merlot.tools.ietf.org:31415/doc/draft-ietf-ipsecme-ikev2-redirect/history/>
>>>
>>> Also...
>>>>
>>>> I realize that the fact that the Etag varies here is going to be a
>>>> problem (it's because the Etag is calculated after the gzip), but this
>>>> is a separate problem.
>>>>
>>>
>>> ...the etag is *supposed* to be different across varying
>>> content-encodings...
>>
>> Yes, of course, but in this case it varies with the same encoding (because
>> we are just using an md5 of the returned data, and the metadata in the gzip
>> header is varying, even though the page contents are the same).
>>
>> Thanks for the redbot pointer!
>
> Um, if the payload changes the (strong) etag needs to change as well, right?

The data that you get as a result of decompressing the payload does
not change.  The bits in the stream that are different are thrown away
while decompressing.

> So *why* is the metadata in the gzip header changing?

The gzip encoder follows the "If the compressed data did not come from
a file..." part of the spec:

         MTIME (Modification TIME)
            This gives the most recent modification time of the original
            file being compressed.  The time is in Unix format, i.e.,
            seconds since 00:00:00 GMT, Jan.  1, 1970.  (Note that this
            may cause problems for MS-DOS and other systems that use
            local rather than Universal time.)  If the compressed data
            did not come from a file, MTIME is set to the time at which
            compression started.  MTIME = 0 means no time stamp is
            available.

so each time you get a gzip stream you get a different MTIME.

> (greetings to Bejing!)

(greetings from Beijing!)

  Bill