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@xxxxxxxxxxxxx] Sent: Wednesday, 25 August 2010 8:46 PM To: squid-users@xxxxxxxxxxxxxxx Subject: Re: 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
