Re: [squid-users] Need help with a Reverse proxy situation

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Tue, 15 Jul 2008 22:56:12 +1200

Michael Alger wrote:
> On Tue, Jul 15, 2008 at 03:39:46AM +0900, Patson Luk wrote:
>> We are using SQUID 3.0 as a reverse proxy on our server and it
>> boosts the performance a lot!
>>
>> However, we have problems when some of the requests are coming in
>> as XML files. On several forums there are mentions that SQUID is
>> only HTTP 1.0 compliant hence those XML files comes in as chunked
>> code-encoding in HTTP1.1 would fail with error code 501 (Not
>> Implemented)

This is a well known bug with certain releases of squid.
http://squidproxy.wordpress.com/2008/04/29/chunked-decoding/

   # 'Fix' broken sites by removing Accept-Encoding header
   acl broken dstdomain ...
   request_header_access Accept-Encoding deny broken

>>
>> I have tried SQUID 2.6 but we still get TCP_DENIED/501 in the
>> access.log
>>
>> There are several ways I can think of that might fix the
>> problem...but I dun quite know how to implement them :( (SQUID and
>> our server are on the same machine)
>>
>> 1. Make SQUID to ignore all the PUT/POST request ...but as far as
>> SQUID is trying to forward them...it fails
>
> I think you're probably correct in that squid can't deal with it
> properly, as HTTP/1.1 support is both very basic and experimental so
> far. As far as I can tell, the support in 2.6 is mostly a workaround
> to fix specific problems (servers returning chunked encoding in response
> to HTTP/1.0 requests), and not a general solution.
>
> I do somewhat wonder why the clients are sending HTTP/1.1 requests
> to a HTTP/1.0 server in the first place, but I'm not exactly sure
> how "negotiation" occurs since the client doesn't know the version
> of the server until after it has sent its request.

Client sending HTTP/1.1 is fine. All the request contains is optional
values which the server considers when sending the reply. BUT it MUST
NOT send a response of higher HTTP version than the client used. Usually
not allowed to send anything but plain text anyway unless the client
allows other stuff.

Squid will send the 1.0 response just fine to a 1.1 client, using 1.0
methods. The 1.1 problems seen are occuring with 1.1 servers sending
back data (like chunked encoding) when Squid sent a 1.0 request out with
certain 1.1 headers it got from the client.

>
>> 2. Make SQUID to only catch/forward requests on certain domain
>> name. For example we have domain name a.com and b.com both runs
>> on the SAME IP, SAME machine...is it possible to configure SQUID
>> such that it only touches/forwards stuff that comes in as a.com
>> but b.com just does not get thru SQUID at all?
>
> I don't think this is possible, as you'd need to bypass squid at the
> network layer, before the client makes a connection to squid. At
> that point the only things you have to go on are the IP addresses
> and ports in the connection request -- the domain name being
> requested isn't known until the connection has been established and
> the HTTP request is sent.

Right. Its impossible for squid to do this. That has to be done at the
browser. But if its just chunked encoding, see the hack above.

>
> If possible, I'd try to get another IP address for the system as
> that would probably be the cleanest way to handle it, assuming you
> can force all the "bad" requests to go to a particular IP address.
>
>> 3. (least favorite) Put some stuff on top of SQUID (that can
>> forward to different PORT based on request type/domain name), etc.
>> if its a GET request, forward to PORT 83 (with caching) and PORT
>> 80 for other request types. A servlet can probably do it...but I
>> really dun want to :(
>
> This is probably what you'll need to do. If you're familiar with
> Apache it might be worth looking at mod_proxy; possibly it has
> better support for chunked encoding. Then again, it might not.

Luckily not.

Amos

-- 
Please use Squid 2.7.STABLE3 or 3.0.STABLE7
Received on Tue Jul 15 2008 - 10:56:07 MDT

This archive was generated by hypermail 2.2.0 : Wed Jul 16 2008 - 12:00:04 MDT