Re: dont-revalidate Cache-Control header

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 <mnot@mnot.net> wrote:

>
> > On 15 Jul 2015, at 7:13 pm, Guille -bisho- <bishillo@gmail.com> wrote:
> >
> >
> > On Tue, Jul 14, 2015 at 5:36 AM, Ben Maurer <ben.maurer@gmail.com>
> 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/
>
>
>
>
>