Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am hosting a REST service which is sending appropriate cache-control headers. I use Varnish as a caching server in front of my webserver. However, a limitation of varnish is that it doesn't support caching HTTP POST and HTTP PUT. Is there any alternate caching server that will be able to cache these requests?

I understand that caching POST is a bit tricky because you cannot just cache based on the url as a key like for GET; it needs to actually inspect the request body. In case of multipart/form-data requests, there should probably be a limit on the size of the request body for it to be cached (so that big file uploads, etc won't be cached). Nevertheless I really want to be able to cache short HTTP POST, or at least the application/x-www-form-urlencoded ones.

share|improve this question
up vote 1 down vote accepted

The main idea of caching is to provide same responses to the same request without asking a back-end system. The problem with POST requests is, that you have to inspect the body to decide when two requests are the same. The best solution is to change from POST to GET.

If this is not applicable you can try Nginx' proxy module with following setup (see the required limitation of the body size):

location @apache_backend {
    proxy_cache_methods   POST;
    proxy_cache_key       "$uri|$request_body";
    client_max_body_size  1k;
share|improve this answer
I had to remove the client_max_body_size. I thought that for requests > 1k it would bypass the proxy, but it will completely deny the request. – Jeroen Apr 22 '12 at 0:03
You know the behavior with using the POST's body for cache is more or less bound to a limit. It might be a little bigger than 1k but this is more or less right. So you have to decide whats more important, to cache POSTs or to have big POSTs. – Jens Bradler Apr 22 '12 at 12:33
What do you mean? It seems to work fine if I remove the client_max_body size. The cache db doesn't use the entire body as a key, it uses a md5 hashkey which is always 32 characters. – Jeroen Apr 22 '12 at 20:46
A, that's fine. I found this recommendation by Igor Sysoev. – Jens Bradler Apr 23 '12 at 4:25

You've tagged your question with , but apparently you are not aware of the proxy_cache_methods and proxy_cache_key directives which should allow you to proxy POST responses as well, provided your server makes use of cache control headers for POST responses.

The idea would be to include the POST method with proxy_cache_methods and find a suitable line for proxy_cache_key. The default value of $scheme$proxy_host$request_uri; would not work well as you suspect, but you can choose from the large list of Nginx variables to get something which would fit your needs.

share|improve this answer
Thanks. Could you elaborate a bit on how nginx deals with the concerns mentioned in the post? – Jeroen Apr 12 '12 at 22:18

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.