Apple's HTTP POST caching is a bug | Hacker News Reader

Apple's HTTP POST caching is a bug

mnot.net

175 pointsigrigorik26 comments

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.

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 .

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).

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)

After you've open the bug report, please also submit it to http://openradar.appspot.com/

This is cool, I'm glad people are finding workarounds for Apple products.

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

Apple uses dupes to help determine priority, so filing dupes is usually a good thing to do.

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!

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?)

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.

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.

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...

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

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

Use POST. GET is not meant for that amount of data. Alternatively, GET by a shorter ID.

What do I do about the people who tell me POST is only for actions which change server state?

You write a well documented application that is useful, adheres to as much of REST as you can and leave the theories to other people.

Simultaneously, it seems to indeed be a convention. And why not follow it? Do you have something whose keys really require the numerousness of 8KB of characters?

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.)

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.

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&...

"the cacheability of HTTP is the majority of its value as a network protocol"

...until everything goes SPDY or equivalent.

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

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

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.

Reply on news.ycombinator.com