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