With very simple caching semantics: if the params are the same (and the url is the same, of course), then it's a hit. Is that possible? Recommended?
+2
A:
Of course it's possible. If you want to catch POST requests sent to your server, and cache the data sent back to be re-sent later - no sweat.
The tricky part comes in regarding "state". How do you decide the data you want to send back to the user really should be the same? What if his cookies have changed - does that change the data you want to send back?
How about if the user made a POST request to your homepage, and since the last time he did that, another user sent him a message (using some system inside your site.) You would have to identify that as a change-of-state, and send the new version of your homepage, with a notification about the message to the user the next time he loads the homepage. Even if the POST parameters are the same.
scraimer
2009-03-09 12:50:03
+1 well-reasoned ;-)
David Zaslavsky
2009-03-09 12:56:24
Possible, yes. Violating RFC 2616 (HTTP/1.1), also very likely. Breaking/not working in browsers that expect HTTP/1.1, possible. Take your pick.
Piskvor
2009-03-09 13:18:21
+9
A:
It is theoretically possible to cache POST requests, but it is not recommended. (The protocol you would be implementing would not be HTTP.) The corresponding RFC 2616 states explicitly in section 13 (Caching in HTTP) that POST requests should not be cached.
Some HTTP methods MUST cause a cache to invalidate an entity. This is either the entity referred to by the Request-URI, or by the Location or Content-Location headers (if present). These methods are:
- PUT - DELETE - POST
Diomidis Spinellis
2009-03-09 12:50:42
This section applies to an intermediate cache (like a caching proxy server), not the origin server.
David Zaslavsky
2009-03-09 12:55:12
True, but they can be interpreted in this context too (and they do make sense).
Cd-MaN
2009-03-09 13:05:50
The origin server is a broker between HTTP and the application that handles the POST requests. The application is beyond the HTTP boundary and it can do whatever it pleases. If caching makes sense for a specific POST request it's free to cache, as much as the OS can cache disk requests.
Diomidis Spinellis
2009-03-09 13:10:49
That is what I meant, that the application running on the origin server is not bound by the HTTP restrictions on caching.
David Zaslavsky
2009-03-09 13:26:50
+4
A:
If it's something that doesn't actually change data on your site, it should be a GET request. Even if it's a form, you can still set it as a get request. While, like others point out, you could cache the results of a POST, it wouldn't make semantic sense because a POST by definition is changing data.
Kibbee
2009-03-09 12:55:37
The POST request might not be changing any data that is used to generate the response page, in which case it could make sense to cache the response.
David Zaslavsky
2009-03-09 13:27:53
+7
A:
Overall:
Basically POST is not an idempotent operation. So you cannot use it for caching. GET should be an idempotent operation, so it is commonly used for caching.
Please see section 9.1 of the HTTP 1.1 RFC 2616 S. 9.1.
Other than GET method's semantics:
The POST method itself is semantically meant to post something to a resource. POST cannot be cached because if you do something once vs twice vs three times, then you are altering the server's resource each time. Each request matters and should be delivered to the server.
The PUT method itself is semantically meant to put or create a resource. It is an idempotent operation, but it won't be used for caching because a DELETE could have occurred in the meantime.
The DELETE method itself is semantically meant to delete a resource. It is an idempotent operation, but it won't be used for caching because a PUT could have occurred in the meantime.
Regarding client side caching:
A web browser will never not forward your request because it has a previous response from a POST operation. For example you may send emails with gmail a couple days apart. They may be the same subject and body, but both emails should be sent.
Regarding proxy caching:
A proxy HTTP server that forwards your message to the server would never cache anything but a GET or a HEAD request.
Regarding server caching:
A server by default wouldn't automatically handle a POST request via checking its cache. But of course a POST request can be sent to your application or add-in and you can have your own cache that you read from when the parameters are the same.
Invalidating a resource:
Checking the HTTP 1.1 RFC 2616 S. 13.10 shows that the POST method should invalidate the resource for caching.
Brian R. Bondy
2009-03-09 13:04:28
+1
A:
According to RFC 2616 Section 9.5:
"Responses to POST method are not cacheable, UNLESS the response includes appropriate Cache-Control or Expires header fields."
So, YES, you can cache POST request response but only if it arrives with appropriate headers. In most cases you don't want to cache the response. But in some cases - such as if you are not saving any data on the server - it's entirely appropriate.
Note, however many browsers, including current Firefox 3.0.10, will not cache POST response regardless of the headers. IE behaves more smartly in this respect.
Now, i want to clear up some confusion here regarding RFC 2616 S. 13.10. POST method on a URI doesn't "invalidate the resource for caching" as some have stated here. It makes a previously cached version of that URI stale, even if its cache control headers indicated freshness of longer duration.