Incomplete responses and immutable

[mnot]

Just wondering out loud -- should immutable have any consideration of whether the response is incomplete, or potentially incomplete (i.e., close-delimited, rather than byte-counted or chunked or h2)?

One of the reasons people hit 'reload' is when something on the page seems corrupted.

@mcmanus any thoughts?

[mcmanus]

so firefox calls this "strongly vs weakly framed".

Hitting reload, which normally does conditional revals, doesn't really help with weakly framed things because you just revalidate the etag or LM in the header.. and in the case of truncation (the common fail mode) the header is not what's wrong.

so if you're weakly framed we don't do conditional revals at all - we just load unconditionally (the same as if you did a hard reload) because its not really trustworthy.

none of this is really an immutable specific issue though. immutable never bypasses 'hard reloads' and that's the only thing that's going to work here..

[mnot]

I was wondering if weakly framed content should be unconditionally be requested on a "normal" load, even despite the presence of immutable.

See also whatwg/fetch#524

[mcmanus]

you mean in normal reloads not normal loads, right? (the latter would just mean no-store I think.)

and yes, that's what I believe we do.. and it isn't related to the presence of immutable. (Though I admit I think I put it in at the same time as working on immutable because these questions came up.)

[mcmanus]

a large component of weakly framed responses are actually buggy responses that we tolerate due to server errors.. e.g. chunked without a 0 chunk or stuff that is short of its content-length

[mnot]

The current draft says:

Clients SHOULD NOT issue a conditional request during the response’s freshness lifetime (e.g. upon a reload) unless explicitly overridden by the user (e.g. a force reload).

What about amending it to:

Clients SHOULD NOT issue a conditional request during the response’s freshness lifetime (e.g. upon a reload) unless explicitly overridden by the user (e.g. a force reload), or when the stored response is potentially corrupted (e.g., lacks strong framing).

?

[mcmanus]

I think we ought to close this issue as not relevant in any special way to immutable.

The issue you are talking about is that conditional reloads do not work for fixing corrupted content because they re validate headers and not the corrupted content. The presence of immutable doesn't really matter to that equation - all it does is bypass a conditional request that wasn't working right anyhow because it is unaware the corruption is in the message body. You can insert this proposed rule to 'fix' that, but it doesn't fix all the resources without immutable that have the same problem for the same reason. The problem has nothing to do with immutable.

I could support a rule for all resources that says clients SHOULD NOT issue a conditional revalidation when the stored response is potentially corrupted (i.e. they should do force reloads) - indeed that's firefox policy. but its not really immutable specific.

[mnot]

Fair enough. I'll raise an issue on the http11bis repo.