Re: [squid-users] Squid, Tomcat and SESSIONID

From: Amos Jeffries <>
Date: Sat, 20 Aug 2011 15:20:04 +1200

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
_OBSOLETE_ RFC 2068 section 10.3.3 under "302 Moved Temporarily"
  (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
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.


Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.14
   Beta testers wanted for
Received on Sat Aug 20 2011 - 03:20:12 MDT

This archive was generated by hypermail 2.2.0 : Sat Aug 20 2011 - 12:00:02 MDT