Add a max-age=0 patch for some versions of Safari. #9

Merged
merged 1 commit into from Jul 6, 2014

5 participants

@chaaz

Some versions of Safari (at least my version, 7.0.3 OSX) will send
Cache-Control:max-age=0 instead of the usual Cache-Control:no-cache when
refreshing a page, after deleting the cache. It expects the server to
respond with up-to-date data. However, if the server response with a
304, then Safari will display a blank page to the user.

This very simple patch treats "max-age=0" the same as it does
"no-cache": it automatically treats the request as fresh, regardless of
other parameters.

@chaaz chaaz Add a max-age=0 patch for some versions of Safari.
Some versions of Safari (at least my version, 7.0.3 OSX) will send
Cache-Control:max-age=0 instead of the usual Cache-Control:no-cache when
refreshing a page, after deleting the cache. It expects the server to
respond with up-to-date data. However, if the server response with a
304, then Safari will display a blank page to the user.

This very simple patch treats "max-age=0" the same as it does
"no-cache": it automatically treats the request as fresh, regardless of
other parameters.
4987647
@btmdave

Any update if this will get added in? It's pretty breaking.

@imyller

I agree with @btmdave; this needs to be added in.

Just tested with Safari 7.0.4, node-fresh 0.2.2, express 4.4.3:

On page reload, Safari sends Cache-Control: max-age=0 instead of Cache-Control: no-cache

Express then incorrectly responds with 304 resulting in empty page rendered as Safari no longer has a cached copy.

@imyller

Safari is complying to RFC-2616 when it sends Cache-Control: max-age=0. Safari requests end-to-end revalidation when reloading the page manually.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.3

Especially:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4

Specific end-to-end revalidation
The request includes a "max-age=0" cache-control directive, which forces each cache along the path to the origin server to revalidate its own entry, if any, with the next cache or server. The initial request includes a cache-validating conditional with the client's current validator.

node-fresh module should react to max-age=0 by preferring fresh content instead of allowing 304 response.

@jonathanong jonathanong merged commit 00f25e6 into jshttp:master Jul 6, 2014
@jonathanong
jshttp member

okay wtf this was added before but reverted. @dougwilson do you know what's up? i'm just not going to push a release until we solve this

@dougwilson

@jonathanong idk, but it clearly seems like max-age=0 should be forcing a refresh, i.e. I believe this PR is valid.

@dougwilson

Nevermind, it may not be. I'm reading more into RFC 7234 sec 4 still, but yes, max-age=0 is not exactly equivalent to no-cache, but I'm still determining what the exact behavior should be (but the current behavior is not correct, but I think the behavior in the PR is also not correct).

@chaaz chaaz deleted the unknown repository branch Jul 11, 2014
@jonathanong jonathanong added a commit that referenced this pull request Sep 8, 2014
@jonathanong jonathanong Revert "Merge pull request #9 from chaaz/max-age0-patch"
This reverts commit 00f25e6, reversing
changes made to 89f8d3c.
2b14ff4
@jonathanong jonathanong added a commit that referenced this pull request May 12, 2015
@chaaz chaaz Add a max-age=0 patch for some versions of Safari
Some versions of Safari (at least my version, 7.0.3 OSX) will send
Cache-Control:max-age=0 instead of the usual Cache-Control:no-cache when
refreshing a page, after deleting the cache. It expects the server to
respond with up-to-date data. However, if the server response with a
304, then Safari will display a blank page to the user.

This very simple patch treats "max-age=0" the same as it does
"no-cache": it automatically treats the request as fresh, regardless of
other parameters.

closes #9
2065cc6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment