
iOS6 Safari Caching $.ajax Results - mmastrac
http://stackoverflow.com/questions/12506897/ios6-safari-caching-ajax-results/
======
gioele
I would like to defend Safari's behaviour.

To me this problem reads "I was doing something wrong, but it has worked, it
should keep on working". In this case, if there has always been a working
proper way, I think that it is OK to break the bad behaviour and force people
to use the proper one.

As other have pointed out, the spec says: "POST responses should not be
cached, unless you use a Cache-Control header. In that case do whatever Cache-
Control says."

Now, "Cache-Control: max-age=0" may have been working fine up to now, but what
its meaning is "this content is cacheable; please retain it only for 0
second". The first part of the sentence explicitly says that the content is
cacheable, the second part is used by the browser as part of its cache policy.
Please note that you _explicitly_ declared the content as cacheable. Do you
want to _explicitly_ declare your content as not cacheable? Use "Content-
Control: no-cache". Or just do not set Cache-Control and rely on the default
non-cacheable status of POST responses.

The only problem here is that Safari is caching POST responses that have no
Cache-Control header set. Yes that is a bug. But one cannot complain about the
fact that a browser cached a response that has explicitly been said by its
producer to be cacheable.

~~~
masklinn
> Please note that you _explicitly_ declared the content as cacheable.

You also declared that it instantly becomes stale, so the browser _must_
revalidate the entry before returning it. Safari returning a resource with
Cache-Control: max-age=0 without contacting the server beforehand is an
incorrect behavior, goes against the spec and is _not_ defensible.

> But one cannot complain about the fact that a browser cached a response that
> has explicitly been said by its producer to be cacheable.

Yes one can, and the problem is not that it was cached but that _it was
returned_. A stale cached response returned without validation is an incorrect
behavior unless the response also included staleness specifications (which I
can't remember ever seeing in the wild). Revalidating is _not_ optional:
[http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13...](http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.1.1)
[http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13...](http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3)

~~~
gioele
Revalidating is optional. A browser MAY not revalidate if it likes so, unless
you use `must-revalidate`:

<https://tools.ietf.org/html/rfc2616#section-14.9.3>

> A cache MAY be configured to return stale responses without validation, but
> only if this does not conflict with any "MUST"-level requirements concerning
> cache validation (e.g., a "must-revalidate" cache-control directive).

<https://tools.ietf.org/html/rfc2616#section-14.9.4>

> must-revalidate

> Because a cache MAY be configured to ignore a server's specified expiration
> time, and because a client request MAY include a max-stale directive (which
> has a similar effect), the protocol also includes a mechanism for the origin
> server to require revalidation of a cache entry on any subsequent use.

------
cfinke
_Must be in Apple's haste to make iOS 6 zip along impressively they got too
happy with the cache settings._

As a developer, this is one of the most irritating things to see in a bug
report: a smirky uninformed assumption about why the bug exists.

~~~
nmcfarl
Irritating as it maybe, users are doing you a favor by even filing a bug,
something we devs often forget. Bug reports are a gift allowing you to improve
your project, and keep on deving, vs, say, waiting tables.

A friend once worked in a company, where "snark" was considered a valid reason
to mark a bug "wontfix". The company didn't last long. It did sound like fun
while it lasted though.

------
mmastrac
This particular issue is probably lurking in code that I've written. The gist
of the fix is to ensure that Cache-Control: no-cache is explicitly set on
anything you don't want cached.

~~~
firefoxman1
Also consider max-age=0

~~~
simonw
The stackoverflow post says that max-age=0 doesn't work for this particular
case, but no-cache does.

------
ricardobeat
Apple has the power to change the web on a whim. If this isn't fixed it could
cause almost every web-service to actually send a `Cache-Control: no-cache`
header on it's POST responses. A long shot, but maybe they are doing this
deliberately (like they did with <video> vs flash) for some reason?

~~~
masklinn
Pretty unlikely, especially undocumented anywhere. I'd ascribe that to
stupidity rather than malice and would guess they tried to change something in
the caching subsystem (e.g. cache POST with an explicit cache-control spec —
makes sense for a mobile phone) and they broke the default case.

This would be supported by max-age: 0 failing to make resources "uncacheable".

------
DanielRibeiro
Duplicate of : <http://news.ycombinator.com/item?id=4550441>

