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

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Fri, 12 Aug 2011 06:44:35 +1200

On 12/08/11 06:22, Rejaine Monteiro wrote:
>
> I agree that the application has serious problems and has already been
> passed it to developers. But I can't do more about it? It is outsourced
> application and they claim that the problem is my proxy and the
> application of them, because all other proxy servers that they tested
> the problem does not occur. For them, the problem is here, with my Squid.
>
> Em 11-08-2011 13:40, Amos Jeffries escreveu:
>> Then those proxies are either not supporting caching of 302 responses
>> or getting different responses to the ones you show here.
>
> This setting below could solve this problem? Because I tried here and
> not relieving effect.
>
> acl broken302 http_status 302
> cache deny Broken302
>
> I thank you!
>

"cache" ACLs are only run on receiving the request, not the reply. So
too early to know.

refresh_pattern only runs on things already stored and can at most
extend caching times affecting the followup.

url re-writing only happens on request. again too late, its already
reached the browser.

location header re-writing is not supported by squid-3.

header replacement only occurs on delivery to external services. nice
for them, but too late for the object already stored.

using a deny_info to bounce requires a fixed location to bounce to
different from the original. It appears your app is using the 302 to
bounce to a login page. so is likely to bounce the bounce back to the
jsessionid URL anyway.
   But you could try this:
     acl site dstdomain ...
     deny_info http://...:8080/session.do?app=portal site
     http_access deny site

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.14
   Beta testers wanted for 3.2.0.10
Received on Thu Aug 11 2011 - 18:44:42 MDT

This archive was generated by hypermail 2.2.0 : Fri Aug 19 2011 - 12:00:02 MDT