Is it possible to cache POST methods in HTTP?

Question

With very simple caching semantics: if the parameters are the same (and the URL is the same, of course), then it's a hit. Is that possible? Recommended?

Answer 1

The corresponding RFC 2616 in section 9.5 (POST) allows the caching of the response to a POST message, if you use the appropriate headers.

Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource.

Note that the same RFC states explicitly in section 13 (Caching in HTTP) that a cache must invalidate the corresponding entity after a POST request.

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

It's not clear to me how these specifications can allow meaningful caching.

Answer 2

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.

Answer 3

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 always forward your request even if it has a response from a previous 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.

Answer 4

If you do cache a POST response, it must be at the direction of the web application. This is what is meant by "Responses to this method are not cachable, unless the response includes appropriate Cache-Control or Expires header fields."

One can safely assume that the application, which knows whether or not the results of a POST are idempotent, decides whether or not to attach the necessary and proper cache control headers. If headers that suggest caching is allowed are present, the application is telling you that the POST is, in actuality, a super-GET; that the use of POST was only required due to the amount of unnecessary and irrelevant (to the use of the URI as a cache key) data necessary to perform the idempotent operation.

Following GET's can be served from cache under this assumption.

An application that fails to attach the necessary and correct headers to differentiate between cachable and non-cachable POST responses is at fault for any invalid caching results.

That said, each POST that hits the cache requires validation using conditional headers. This is required in order to refresh the cache content to avoid having the results of a POST not be reflected in the responses to requests until after the lifetime of the object expires.

Answer 5

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.

Answer 6

Mark Nottingham has analyzed when it is feasible to cache the response of a POST. Note that the subsequent requests that want to take advantage of caching must be GET or HEAD requests. See also httpbis

POSTs don't deal in representations of identified state, 99 times out of 100. However, there is one case where it does; when the server goes out of its way to say that this POST response is a representation of its URI, by setting a Content-Location header that's the same as the request URI. When that happens, the POST response is just like a GET response to the same URI; it can be cached and reused -- but only for future GET requests.

https://www.mnot.net/blog/2012/09/24/caching_POST.

Answer 7

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.

Answer 8

With firefox 27.0 & with httpfox, on May 19, 2014, I saw one line of this: 00:03:58.777 0.488 657 (393) POST (Cache) text/html https://users.jackiszhp.info/S4UP

Clearly, the response of a post method is cached, and it is also in https. Unbelievable!

Answer 9

POST is used in stateful Ajax. Returning a cached response for a POST defeats the communication channel and the side effects of receiving a message. This is Very Very Bad. It's also a real pain to track down. Highly recommended against.

A trivial example would be a message that, as a side effect, pays your salary $10,000 the current week. You DON'T want to get the "OK, it went through!" page back that was cached last week. Other, more complex real-world cases result in similar hilarity.