Re: dont-revalidate Cache-Control header

[Mark Nottingham <[e-mail]>]

Note:
  http://httpwg.github.io/specs/rfc7234.html#incomplete.responses

Cheers,


> On 16 Jul 2015, at 11:56 am, Ben Maurer <[e-mail]> wrote:
> 
> To take this a step further, it's really critical that UAs do not cache resources in any situation where the connection is closed or aborted prior to receiving the full Content-Length number of bytes or the terminal chunk in chunked encoding. There's no good way for a user to fix this kind of situation other than clearing their cache -- if they refresh with ctrl+r, they would generally get a 304 on the resource. We actually went through a round of testing this behavior at FB while we were tracking down a bug, but I'm struggling to find our results since it was a long time ago.
> 
> Servers should probably not send long expiration headers on a connection that is delimited by connection close unless they are able to send a Content-Length header. In practice we haven't seen this be an issue because nearly all UAs are able to get chunked responses.
> 
> -b
> 
> On Thu, Jul 16, 2015 at 10:25 AM, Mark Nottingham <[e-mail]> wrote:
> 
> > On 15 Jul 2015, at 7:13 pm, Guille -bisho- <[e-mail]> wrote:
> >
> >
> > On Tue, Jul 14, 2015 at 5:36 AM, Ben Maurer <[e-mail]> wrote:
> > static
> >
> > If corruption is still a concern (not sure if it is because https will give us better integrity guarantees), what about an optional checksum? static=<type>:<hash> like static=SHA1:###... ?
> >
> > That could help preventing corruption for items that are going to stay in cache forever. It doesn't need to be mandatory neither on origin nor clients to validate it, but intermediate proxies/browsers can be more sure that the content they are storing is non-corrupted.
> 
> At the least, we should have language to the effect that this directive (however conveyed) is only valid if the response is complete, and connection close was NOT used to delimit the response.
> 
> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 
> 
> 
> 

--
Mark Nottingham   https://www.mnot.net/