13 ms·

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 an

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.
        damncabbage 14y ago
        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&...
gojomo 14y ago
"the cacheability of HTTP is the majority of its value as a network protocol" ...until everything goes SPDY or equivalent.

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

gojomo 14y ago

"the cacheability of HTTP is the majority of its value as a network protocol" ...until everything goes SPDY or equivalent.