RE: [squid-users] Regarding long pauses with Squid3 as a reverse proxy to Exchange 2010 OWA

Amos,
Thank you for your analysis and comments. I appreciate them greatly.

I have looked at another packet capture for a session between the client
browser and exchange 2010 OWA via http but without squid in between them.
The headers are as below:

GET /owa/14.0.702.0/scripts/premium/startpage.js HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword,
application/x-shockwave-flash, application/x-ms-application,
application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml,
*/*
Accept-Language: en-au
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022;
.NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Host: the.exchange.server
Connection: Keep-Alive

HTTP/1.1 200 OK
Cache-Control: public,max-age=2592000
Transfer-Encoding: chunked
Content-Type: application/x-javascript
Content-Encoding: gzip
Last-Modified: Fri, 25 Sep 2009 04:59:56 GMT
Accept-Ranges: bytes
ETag: "c08cce69d3dca1:0"
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
X-UA-Compatible: IE=EmulateIE7
Date: Wed, 25 Aug 2010 05:19:21 GMT

The browser (IE7) is using HTTP 1.1. Apart from the GET request specifying
HTTP 1.1 there is no difference to the request sent by squid included in my
original email.

However, I notice that this time IIS replies with a Transfer-Encoding header
(chunked) which was not present in the scenario where squid was acting as a
reverse proxy. All the other headers are the same as when using squid.

Also, there is still no Content-Length header sent by IIS.

I am not familiar with the HTTP specifications at all. Is it OK that squid
sends a HTTP 1.0 request with an Accept-Encoding header or is the issue with
chunked Transfer-Encoding?

Is IIS actually not replying correctly to a HTTP 1.0 request?

I will take a look at the packet captures to see if IIS is sending the FIN at
the completion of sending the request data.

Regards

Paul
-----Original Message-----
From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
Sent: Wednesday, 25 August 2010 8:46 PM
To: squid-users_at_squid-cache.org
Subject: Re: [squid-users] Regarding long pauses with Squid3 as a reverse
proxy to Exchange 2010 OWA

Paul Freeman wrote:
> Apologies in advance for the long posting. I have tried to provide what I
> hope is sufficient information to explain a problem I am experiencing.
>

Excellent collection of details. Thank you.
I'm going to snip most of them

After reading I have a theory ...

A detailed look at the wireshark trace packets during the lag period
will be needed to verify.

  The reply HTTP headers coming from Exchange appear to have no
Content-Length: header telling Squid how much data is following. This
places responsibility for FINishing the connection squarely in Exchanges
hands.

  What needs checking in wireshark is whether Exchange actually sends
that FIN packet following the object data.
  Unless there is some secret information OWA knows about to close the
transaction from its end, there is no way for Squid or OWA to know the
end has come. So they wait.

You may find that 3.1.7 fairs better since it advertises 1.1 to Exchange
and that may be enough to fool Exchange into handing back some useful
information such as the object chunk sizes to Squid.
  I may be able to provide a source package bundle in a few days for
that if you need one.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.7
   Beta testers wanted for 3.2.0.1
 
__________ Information from ESET Smart Security, version of virus signature
database 5397 (20100825) __________
The message was checked by ESET Smart Security.
http://www.eset.com
 
 
__________ Information from ESET Smart Security, version of virus signature
database 5397 (20100825) __________
The message was checked by ESET Smart Security.
http://www.eset.com