RE: [squid-users] Cache-Control problems with Korean sites

On Tue, 21 Jul 2009 10:09:32 -0400, Mike Mitchell <Mike.Mitchell_at_sas.com>
wrote:
> I used telnet to connect to the problem web server and sent a minimal
HTTP
> request. The web server returned a page, so I tried again adding a
header
> from the trace one at a time until I did not get a response. I only
tried
> one value of Cache-Control, max-age=0.
>
> I've tried accessing the Korean Government sites from other proxy servers
> around the world and I get the same behavior. I know the problem isn't
> with the proxy server's ISP, but rather with the Korean Government sites.

Okay so its definitely that issue then. Very strange.

The safe approach is to leave the site inaccessible and nag their admin(s)
until its fixed.

The header stripping may be the best short-term workaround if the above is
not an option. Being squid-2 it will also need a bit more work to make it
safe and not strip the reply controls (think of your Squid acting as a
Cache-Control: private remover for government security logins).
 * Try to strip the reply controls: I'd add an external ACL that takes only
the _request_ Cache-Control header and returns false if its missing.

I'd also add a "cache deny NoCacheCtl" rule to prevent your Squid being
poisoned by any bad data coming back.

And most definitely track down someone who can look at the issue and nag
them until its fixed. I can't stress how important that is.

Amos

>
> Mike Mitchell
>
> -----Original Message-----
> From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
> Sent: Tuesday, July 21, 2009 2:37 AM
> To: Mike Mitchell
> Cc: squid-users_at_squid-cache.org
> Subject: Re: [squid-users] Cache-Control problems with Korean sites
>
> Mike Mitchell wrote:
>> We're having problems accessing Korean Government sites like
>> parcel.epost.go.kr and www.g2b.go.kr<http://www.g2b.go.kr> from a squid
>> cache that is physically in Seoul, Korea. I performed network captures
>> and found that if the request included a 'Cache-Control' header the
>> remote server did not send TCP ACK messages back for the request. The
>> remote server did complete the three-way TCP connection handshake, but
>> would not acknowledge the request. When I stripped the 'Cache-Control'
>> header using
>>
>> acl NoCacheCtl dstdomain .epost.go.kr .gtb.go.kr
>> header_access Cache-Control deny NoCacheCtl
>>
>> the TCP ACKs started coming back and we could retrieve content.
>>
>> My guess is there is a firewall protecting the remote web servers. Has
>> anyone seen this behavior before?
>
> Any cache-control values? or just specific ones?
>
> It's really up to whoever runs the broken software to fix the issue.
> Just find out where the breakage is and yell loudly at them.
>
> Amos
> --
> Please be using
> Current Stable Squid 2.7.STABLE6 or 3.0.STABLE16
> Current Beta Squid 3.1.0.10 or 3.1.0.11
Received on Wed Jul 22 2009 - 04:28:48 MDT