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

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 2

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 3

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 4

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 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

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.