W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: ID for Immutable

From: Patrick McManus <pmcmanus@mozilla.com>
Date: Fri, 28 Oct 2016 11:01:12 -0400
Message-ID: <CAOdDvNpi=TxEf+W5vX8V3rCh8yB2P14pgO6bFXKthODRaU_y-g@mail.gmail.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP working group mailing list <ietf-http-wg@w3.org>
Hey Kari, In my distaste for response header hashes, I did hastily neglect
to mention that one of my implementation corner cases was to ignore
immutable in cases of weakly framed content.. we define weakly framed as
responses terminated by EOF or with Content-Lengths that don't match, or
chunked encodings without a 0 chunk at the end. Experience has shown that
we have to accept these responses for reasons of interop - but discretion
says to ignore immutable on them as they may be indications of corruption.
The ID should mention this - I'll put in -01. Thanks.

worth noting here that the refresh conditional-request path that immutable
impacts has never helped much with the corruption case.. it conditionally
verifies etags or l-m, but generally the corruption is in the message body
- most often truncation. so a 304 reply confirms to the client to keep
using the corrupted content anyhow.. that's there is often a force (or
hard) reload option that goes with no-cache and the draft tries to point
out you really shouldn't use immutable to shortcut that. We use this
force-reload path in lieu of revalidations for weekly framed things.


On Fri, Oct 28, 2016 at 10:50 AM, Patrick McManus <pmcmanus@mozilla.com>
wrote:

> the notion of integrity hashes have failed in the past (notably md5)..
> separable from immutable imo and would rather not tie that anchor to its
> fate.
>
> On Fri, Oct 28, 2016 at 10:44 AM, Kari Hurtta <
> hurtta-ietf@elmme-mailer.org> wrote:
>
>> > Htmlized:       https://tools.ietf.org/html/draft-mcmanus-immutable-00
>>
>> |    o  User-Agents often provide two different refresh mechanisms: reload
>> |       and some form of force-reload.  The latter is used to rectify
>> |      interrupted loads and other corruption.  These reloads should
>> |      ignore immutable as well.
>>
>> How about making it
>>
>> Cache-Control: max-age=31536000, immutable=<hash-function-value>
>>
>>
>> So that immutable does not have effect if result of hash-function
>> does not give same value that what is value of immutable
>> cache control.
>>
>> Several immutable cache controls are invalid if they are result
>> of same hash-function.
>>
>> If server can't calculate hash-function over resource,
>> is is really static non-caching resource?
>>
>> I think that this protects agaist that interrupted loads
>> becomes immutable.
>>
>> / Kari Hurtta
>>
>>
>
Received on Friday, 28 October 2016 15:01:43 UTC

This archive was generated by hypermail 2.3.1 : Friday, 28 October 2016 15:01:46 UTC