

Apple's HTTP POST caching is a bug - igrigorik
http://www.mnot.net/blog/2012/09/24/caching_POST

======
codeka
I don't understand this, the line in the RFC is clear:

> Responses to this method are not cacheable, unless the response includes
> appropriate Cache-Control or Expires header fields.

That is, if you don't include a Cache-Control header, the response is not
cacheable. Why is this even controversial? It's a bug.

~~~
gioele
Caching without a Cache-Control header is a bug, agreed. The point is that in
the original bug report the Cache-Control header was set in a way that implied
the resource to be cacheable, but only for 0 seconds. This kind of
declarations are perfect "worms' can openers".

For a longer, more detailed discussion with references to the RFC, see
<https://news.ycombinator.com/item?id=4552251> .

~~~
codeka
As far as I can tell, the original report doesn't actually say whether there's
no Cache-Control header at all or whether it set to max-age=0.

I would still argue that caching a POST response with max-age=0 (and no max-
stale) is a bug because, while the standard technically allows it, it also
technically allows the client to immediately invalidate it and immediately
invalidating is the saner choice (at least, it's the choice that is going to
break fewer websites).

------
igrigorik
If you care about this, and you should.. Please open a bug to fix this:
radar.apple.com

(unfortunately we cannot see bugs opened by others)

~~~
othermaciej
FYI, we already have bugs tracking this. It can't hurt to file dupes but it's
also not required.

~~~
mikeash
It seems that about half the time, Apple people tell us to file duplicates
because it helps prioritize things, and the other half of the time they tell
us not to file duplicates because it's already being tracked. This is really
confusing!

~~~
kimon
each product team at Apple is different. some pay close attention to duplicate
counts when prioritizing radars, others don't.

if instead you wanted to read between the lines: please file a dupe (we have
no idea when that will be fixed.) no need to file a dupe (oh cute, you're
still running that ancient public build?)

------
snorkel
No need to argue over RFC semantics on this one, as everyone agrees POST
should not be cached, many web services are designed around that assumption,
and clearly Apple needs to fix this. Most web traffic is GET responses, so the
added advantage of caching POST would be very marginal, not worth breaking the
web over.

------
AffableSpatula
browser vendors should be pressured to up their game with regards to web
caching. The cacheability of HTTP is the majority of its value as a network
protocol and browsers - the defacto HTTP client - just aren't pulling their
weight in this regard.

Support for new cache-control directives like stale-if-error, and some kind of
API for negotiating/allocating cache storage for web apps would be a good
place to start, imo.

~~~
jrabone
Not just browser vendors - to do this effectively a lot of companies need to
"get" RESTful APIs in a way that they just don't at the moment. For example,
think about fat clients that are actually talking HTTP, maybe through an ISP
transparent proxy. If they're "misusing" REST in the myriad usual ways,
they'll be very surprised if that proxy becomes a cache instead.

Not to get all Bladerunner here, but I've seen things you people wouldn't
believe. PUTs of URI-encoded XML queries in the request URL, right up until
the HTTP server says "Nope, 8K is your limit" for a start...

~~~
damncabbage
_PUTs of URI-encoded XML queries in the request URL, ..._

Or POST-only AJAX requests because an out-of-the-box install of a package
wants to put 5KB of data into the URL: <http://drupal.org/node/956186>

~~~
lollerpops
So what's the fix? I want to GET something that has an 8k long name. What do I
do?

~~~
damncabbage
I have an 8-foot toenail that needs a little clipping; what tool should I use?

More seriously, what needs an 8KB-long name?

(That bug post contains a few workarounds that'll let Drupal get back to GET
for one of the listed cases. Drupal's case is particularly pathological as
it's trying to be everything to everybody; it's like being a handsaw AND a
sander AND a varnish for the floor AND a dessert topping.)

~~~
lollerpops
A file storage service, ala dropbox, that allows you to select multiple files
and download them as a zip. The concatenation of several uuids adds up
quickly.

~~~
damncabbage
Good point. Unbounded requests (hundreds or more of ten-char IDs) are
definitely candidates for a POST workaround. It's a shame, but necessary. :S

My main beef with Drupal is that it uses POST for _everything_ , whether it's
to /jobs/1234 or to _/files/?id[]=1234 &id[]=3452&..._

------
mratzloff
Perhaps while they're fixing this they can also revert the terrible, unusable
new web inspector that launched with Safari 6.

------
tlrobinson
I'd love to hear their reasoning for introducing this bug, assuming it was
intentional.

~~~
powatom
Same - if they're intentionally violating the spec then I'd really love to
know why. I suspect this is just something that wasn't caught by testing / QA
before release.

