Matt Menke

[@morlovich] Keying cache entries on credentials mode certainly makes sense to me, at least. I believe we've historically depended on/assumed/hoped folks would use vary: cookies if they cared about credentials,...

The fact that a site may get an older copy of the resource depending on the credential bit does seem confusing - maybe it would make more sense to just...

There seem to be a little different from NPK to me, at least. NPK is currently best-effort privacy, and the model assumes all sites are the attackers (including intermediate caches,...

I think that's a different issue. If Chrome sees a content-length for a resource with a chunked transfer encoding, I believe it ignores the content-length. That comment was about the...

That's another issue - due to the linear nature of time, it's not always possible to know if there are more bytes on the wire after you've received 1000 bytes,...

Also, the extra bytes could be, e.g., in case of latency, a 418 (?) connection timeout response, which isn't actually an error about the previous request.

I should add, it's possible to check if there are any bytes currently pending on a socket, and read them if there are, and don't do anything if there aren't,...

Even non-keepalive connections can specify a length, and could theoretically have extra bytes on the wire, which I think corresponds to the case this is trying to consider an error?...

That may introduce hangs in the case of currently cross-browser functional servers that expect browsers to close non-keepalive connections that specify lengths (which may be an uncommon enough case that...

That response is a 206 with a content-encoding - the request should be treated as a failure because of that, if for no other reason.