Re: force POST requests to be cached?

Perrin Harkins wrote:

> My circumstances may be unique. I run a search engine which my
> main application accesses using HTTP. The only reason I'm using
> POST rather than GET is the size of the parameters that I pass
> to the search engine, which exceed the limit on GET in the HTTP
> server I'm using. (It's part of the search engine, so I can't
> switch to Apache.)

I don't think your circumstances are unique, but the bad news is that
HTTP does not provide a way to negotiate caching in this way.

Bad news is that all available cache control in HTTP is based on request
URI and headers, not request body. If caching based on request bodies is
to be done then it has to be based on a private HTTP extension.

Other bad news is that the current Squid code can't look into request
bodies in a way that is suitable for this. If I manage to port my
request-body processing code to Squid 2.0 then may it be possible to get
around this limitation in Squid for requests of limited size (4 or 8kb).

Proposed HTTP extension:
  (X-)Request-MD5:
        MD5 digest of request entity-body for the purpose of allowing cache
negotiaton based on the request entity-body of a POST or similar
request.

If Squid could calculate this header on the fly, then Vary: could be
used to negotiate caching of the reply based on the request body.

More bad news is that Squid currently can't cope with Vary: in a general
way.

If the request size is inside the allowable/recommended size of GET
requests, then another option is to add a small frontend server on your
search engine that translates GET requests to POST.

---
Henrik Nordström
Spare time Squid hacker