Re: ID for Immutable

Patrick McManus <pmcmanus@mozilla.com>: (Fri Oct 28 18:01:12 2016)
> 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.. 

So on these case that heuristic that ignore immutable for
"weakly framed content" does not help either. 304 reply
still confirms to the client to keep using the corrupted content.

My suggestion using immutable=<property from bydy> for ignnoring
immutable was making that more explicit than heuristic. But
that does change  is that ignoring usefull or not.

/ Kari Hurtta

Received on Saturday, 29 October 2016 05:50:04 UTC