On 20/08/11 02:51, Rejaine Monteiro wrote:
Unfortunately, none of the suggestions worked .... This is getting
really annoying, because application developers insist on saying that
the problem is with the Squid, since we tested with somes other proxy
servers and not presented the problem ... Don't know what else to do. ..
Implementing the individual caching clauses in HTTP is completely
optional. Squid has implemented one HTTP clause which the other proxies
for some reason have not. Both Squid and those other proxies are all
obeying the RFC 2616 guidelines. The app is not.
Your Squid is just the tip of a massive iceberg of middleware they are
facing. Point those developers at:
RFC 2616 section 10.3.3 under "302 Found" responses
http://www.ietf.org/rfc/rfc2616.txt
or
_OBSOLETE_ RFC 2068 section 10.3.3 under "302 Moved Temporarily"
http://www.ietf.org/rfc/rfc2068.txt
(both are identical for this clause)
"
The requested resource resides temporarily under a different URI.
Since the redirection might be altered on occasion, the client SHOULD
continue to use the Request-URI for future requests. This response
is only cacheable if indicated by a Cache-Control or Expires header
field.
"
That last sentence. "only cacheable if indicated by ..."
HTTP/1.0 302 Moved Temporarily
Date: Wed, 10 Aug 2011 21:53:52 GMT
...
Expires: 15 Aug 2011 21:53:52 GMT
Cache-Control: max-age=120
...
Means cache for 120 seconds (in HTTP/1.1 software) or up to _5 days_ in
older HTTP/1.0 software.
Note the HTTP/1.0 prefix at the start. Squid is still HTTP/1.0 software.
So _5 days_ is what gets used.
As I said at the top. Caching is OPTIONAL. In squid you can turn it off
based on the _request_ details with the "cache allow/deny" access
control. Reply details like the status are too late.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.14
Beta testers wanted for 3.2.0.10
