5 ms·

Apple's HTTP POST caching is a bug

175 points by igrigorik 14y ago

deleted 14y ago
[deleted]
- deleted 14y ago
  [deleted]
AffableSpatula 14y ago
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 14y ago
  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 14y ago
    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 http://drupal.org/node/956186
    - lollerpops 14y ago
      So what's the fix? I want to GET something that has an 8k long name. What do I do?
      - voltagex_ 14y ago
        Use POST. GET is not meant for that amount of data. Alternatively, GET by a shorter ID.
        lollerpops 14y ago
        What do I do about the people who tell me POST is only for actions which change server state?
        voltagex_ 14y ago
        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.
        drivebyacct2 14y ago
        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?
      - damncabbage 14y ago
        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 14y ago
        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.
- gojomo 14y ago
  "the cacheability of HTTP is the majority of its value as a network protocol" ...until everything goes SPDY or equivalent.
igrigorik 14y ago
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)
- sirn 14y ago
  After you've open the bug report, please also submit it to http://openradar.appspot.com/ http://openradar.appspot.com/
  - alpb 14y ago
    This is cool, I'm glad people are finding workarounds for Apple products.
- othermaciej 14y ago
  FYI, we already have bugs tracking this. It can't hurt to file dupes but it's also not required.
  - ksuther 14y ago
    Apple uses dupes to help determine priority, so filing dupes is usually a good thing to do.
  - mikeash 14y ago
    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 14y ago
      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 14y ago
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.
codeka 14y ago
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 14y ago
  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 https://news.ycombinator.com/item?id=4552251 .
  - codeka 14y ago
    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).
mratzloff 14y ago
Perhaps while they're fixing this they can also revert the terrible, unusable new web inspector that launched with Safari 6.
tlrobinson 14y ago
I'd love to hear their reasoning for introducing this bug, assuming it was intentional.
- powatom 14y ago
  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.

175 points by igrigorik 14y ago

deleted 14y ago

[deleted]

deleted 14y ago
[deleted]

AffableSpatula 14y ago

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 14y ago
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 14y ago
  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 http://drupal.org/node/956186
  - lollerpops 14y ago
    So what's the fix? I want to GET something that has an 8k long name. What do I do?
    - voltagex_ 14y ago
      Use POST. GET is not meant for that amount of data. Alternatively, GET by a shorter ID.
      - lollerpops 14y ago
        What do I do about the people who tell me POST is only for actions which change server state?
        voltagex_ 14y ago
        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.
        drivebyacct2 14y ago
        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?
    - damncabbage 14y ago
      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 14y ago
        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.
gojomo 14y ago
"the cacheability of HTTP is the majority of its value as a network protocol" ...until everything goes SPDY or equivalent.

igrigorik 14y ago

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)

sirn 14y ago
After you've open the bug report, please also submit it to http://openradar.appspot.com/ http://openradar.appspot.com/
- alpb 14y ago
  This is cool, I'm glad people are finding workarounds for Apple products.
othermaciej 14y ago
FYI, we already have bugs tracking this. It can't hurt to file dupes but it's also not required.
- ksuther 14y ago
  Apple uses dupes to help determine priority, so filing dupes is usually a good thing to do.
- mikeash 14y ago
  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 14y ago
    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 14y ago

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.

codeka 14y ago

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 14y ago
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 https://news.ycombinator.com/item?id=4552251 .
- codeka 14y ago
  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).

mratzloff 14y ago

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

tlrobinson 14y ago

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

powatom 14y ago
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.