NGINX does not update cache entry headers on 304 response

[Maxim Dounin]

Hello!

On Fri, Jan 03, 2020 at 12:03:59PM +0100, Ladislav Macoun wrote:

> NGINX currently does not update the Expires HTTP header during 
> cache revalidation after receiving 304 response from the origin. 
> This may lead to receiving a response from cache with invalid 
> Expires header, and not loading content from the browser disk 
> cache.
> 
> It looks like this behaviour is intended as Maxim states this in 
> the commit message “As of now, no attempts are made to merge 
> headers given in a 304 response during cache revalidation with 
> headers previously stored in a cache item. Headers in a 304 
> response are only used to calculate new validity time of a cache 
> item.”[1]
> 
> This behaviour seems to present until now, the cache entry only 
> updates the file cache header. And keeps the old response 
> headers.

Yes.

> This behaviour may violate the RFC for 304 Not Modified Response.

Yes.  If you want strictly RFC-complaint behaviour, you are free to 
keep the default value of the proxy_cache_revalidate directive, 
that is, keep it off.

> If a cache uses a received 304 response to update a cache entry, 
> the cache MUST update the entry to reflect any new field values 
> given in the response. [2]
> 
> As I understand this, the cache MUST update the entry fields, 
> which in this case are only headers since origin does not resend 
> the body.
> 
> I would like to ask if this behaviour is correct and my 
> interpretation of the RFC is wrong, or if this behaviour is 
> really intended or there is a bug somewhere else.

It is believed that handling of 304 responses as required by RFC 
is quite problematic for nginx cache storage model, and not needed 
in most cases.  Given that, we intentionally ignore RFC 
requirements here, and keep the proxy_cache_revalidate directive 
switched off by default.

-- 
Maxim Dounin
http://mdounin.ru/