[PATCH 1 of 2] Cache: don't update cache if revalidated response is not cacheable

[Piotr Sikora]

Hey Maxim,

> The cacheability of the response was already signalled previously.
> And a 304 response can't really change it.

Fine, if you want to get technical, then yes, cacheability of the
response was signaled previously, however the 304 response can still
signal that the validity shouldn't be extended (i.e. that the cache
shouldn't be updated), which is what we're really talking about here.

> Consider, for example,
> that there were no validation request at all - and it happens some
> time later.  So the only thing that really changes is validity.

I don't follow your logic here, what exactly are you trying to say?

> That's in line with the RFC2616: it allows 304 to supply new
> Cache-Control and Expires headers if they are different from what
> was previously sent.  So we use validity from the 304 response,
> then from the cached response, then from proxy_cache_valid.
>
> What is probably missing here is not using valid_sec if
> u->cacheable is set.
>
> (...)
>
> I agree, see above.

Which is basically what my patch adds, isn't it?

> The problem is consistency of the behaviour in equivalent cases.
>
> E.g., consider the following:
>
> - A response with Set-Cookie cached with
>   "proxy_ignore_headers Set-Cookie" in the configuration.  The
>   response contains "Cache-Control: max-age=100".
>
> - Now proxy_ignore_headers is removed from the configuration.  We
>   do a request with If-Modified-Since, 304 is returned:
>
>   (a) If the 304 contains "Cache-Control: max-age=100", the
>       response will be cached for 100 more seconds.
>
>   (b) If the 304 does not contain "Cache-Control: max-age=100",
>       the response won't be updated.
>
> On the other hand, (a) and (b) are equivalent per RFC2616.

However, according to RFC7232, (a) and (b) are different:

   The server generating a 304 response MUST generate any of the
   following header fields that would have been sent in a 200 (OK)
   response to the same request: Cache-Control, Content-Location, Date,
   ETag, Expires, and Vary.

   Since the goal of a 304 response is to minimize information transfer
   when the recipient already has one or more cached representations, a
   sender SHOULD NOT generate representation metadata other than the
   above listed fields unless said metadata exists for the purpose of
   guiding cache updates (e.g., Last-Modified might be useful if the
   response does not have an ETag field).

Best regards,
Piotr Sikora