> > does squid distinguish between GET and POST URLs? I have an HTML form > > (as part of a CMS) that will be first requested by "GET /form.html". > > When the user submits the form, a "POST /form.html" will be made, > > including the form data in the body of the request. > > > > I want to "GET" request to be cached, because the result is always the > > same (an empty form), but I want the response to the "POST" request > > not to be cached. > > > > Is it enough to put a > > > > acl POSTs method POST > > no_cache deny POSTs > > > > in squid.conf? > > > > I guess, the first GET request will made squid cache "/form.html", > > and the next POST will find the cached object. The no_cache directive > > just says not to cache the response from the origin server, but I > > guess it does not prevent squid from looking in the cache if there > > is already a "/form.html"... > > > > regards > > -stefan- > > > > According to the HTTP RFC (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) "Responses to [the POST] method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields." "Not cacheable" means, server responses will not be stored in the cache. But does it also mean, that existing objects in the cache will never be *used* for POST requests? After the first "GET /form.html", "form.html" may be stored in the cache, because this is no POST request. The following "POST /form.html" may *use* the stored object (and not sending the POST request to the server). I guess this is not the same as what it meant by "POST requests are not cacheable", because "cachable" means *storing* objects in the cache, but this scenario describes *using* of stored objects... May this really happen? Or will objects retrieved by GET requests never used for POST requests (and vice versa)? -Stefan-
