Do PUT requests get cached by intermediaries?

[toomim]

I'm concerned that the PUT request could be incorrectly cached by intermediaries that don't understand the Braid extensions.

For instance, if we send a PUT with a patch, might a proxy think that the patch is the new value of the resource, rather than just a patch to apply to the resource?

If so, we might need to use a new response code, or cache-control: no-cache, as discussed in #16. Alternatively, we might want to require using the PATCH method instead of PUT.

[mitar]

PUT should never be catched. In any case, post/redirect/get could be used here, too (just put instead).

[toomim]

Let me clarify -- my primary concern is that the response to a PUT request could be cached.

Imagine you're on a corporate LAN behind a Squid HTTP proxy, and do this:

PUT /foo with value "foo"
  => Responds with 200 OK
PUT /foo with a patch that appends " bar"
  => Responds with 200 OK
GET /foo

I'm concerned that the proxy will notice that your previous PUT /foo with a patch responded with 200 OK, and then thinks that the new value of /foo is a patch that appends "bar" instead of "foo bar".

[mitar]

So do redirect always as response to PUT. :-)

[mitar]

See also: https://stackoverflow.com/questions/626057/is-it-possible-to-cache-post-methods-in-http

So interesting is that PUT also invalidates the cache of GET for same URI.

[toomim]

I'm realizing this is an instance of the more general problem of feature detection (issue #89).

The issue occurs when you do a PUT with a content-range header to a server or proxy that doesn't understand content-range. Such a server, or proxy, will ignore the content-range header, and obliterate the entire resource, and replace it with the patch.

I'm closing this issue, and adding a note in feature detection (#89) that we need to ensure it works across proxies as well.