Amos I suspect I may have come across another situation related to chunked Transfer-Encoding although I am not sure yet. I have verified that using a HTC Desire I can successfully sync email, calendar and notes including sending new calendar items and new email and replies to emails. However, when I try this using an iPhone (3GS, running IOS 4.0.1) it cannot send email. Pulling data (calendar, email) from Exchange works OK though. Squid is replying with a 501 error. I have increased debugging on the squid reverse proxy and notice the iPhone is sending a post request, which I have included below (certain private values replaced), which Squid does not like. POST /Microsoft-Server-ActiveSync?User=username&DeviceId=fjsdlfjlsdjflskj&DeviceTy pe=iPhone&Cmd=SmartReply HTTP/1.1 Host: external.server.name Content-Type: application/vnd.ms-sync.wbxml Ms-Asprotocolversion: 14.0 User-Agent: Apple-iPhone2C1/801.306 X-Ms-Policykey: 4281201554 Authorization: Basic asjlfjdal;sjdfl;ajsdf;lajsl;f Accept: */* Accept-Language: en-us Accept-Encoding: gzip, deflate Connection: keep-alive Transfer-Encoding: Chunked What causes Squid to issue a 501 reply? Is it related to Transfer-Encoding? Thanks Paul -----Original Message----- From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] Sent: Thursday, 26 August 2010 10:20 AM To: squid-users@xxxxxxxxxxxxxxx Subject: RE: Regarding long pauses with Squid3 as a reverse proxy to Exchange 2010 OWA On Thu, 26 Aug 2010 08:17:23 +1000, "Paul Freeman" <paul.freeman@xxxxxxxxxx> wrote: > 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? I think it is doing its failover to non-chunked HTTP/1.0 badly. With chunked encoding each 4KB or so chunk of the body is labeled with an indicator of how long it is, and a final empty chunk sent at the end. There is no Content-Length header required because of the known chunk sizes. However in that first trace it was not doing the chunking and thus no size info gets back to Squid at all in the HTTP level stuff. This compatibility problem is resolved in 3.1 series which are HTTP/1.1 toward servers. I have 3.1.3 and supporting packages available for Ubuntu at https://launchpad.net/~yadi/+archive/ppa, with 3.1.7 coming in a week or so when it makes it into Debian. Amos > > Is IIS actually not replying correctly to a HTTP 1.0 request? Yes and no. The HTTP part is valid, but it's maybe failing the TCP/IP level close. > > 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 __________ 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 5407 (20100829) __________ The message was checked by ESET Smart Security. http://www.eset.com
