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

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_at_treenet.co.nz]
Sent: Thursday, 26 August 2010 10:20 AM
To: squid-users_at_squid-cache.org
Subject: RE: [squid-users] 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_at_eml.com.au> 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_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
 

__________ 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
 
Received on Mon Aug 30 2010 - 02:51:29 MDT