I still don't have my answer why it seemed to work internally but not proxied. The extra debug in the 3.3 release (thanks Amos) was certainly helpful, but not enlightening. Frankly, knowing what I now know, I question the original test result. But getting a definitive answer has become more of a scholastic exercise at this point, so I can offer closure on the topic: Exchange 2010 IIS sets a <requestLimit> maxRequestLength that is used for /OWA and other virtual directories. Depending on where you look, this could be anywhere from 30meg to "unlimited". Yet if RequestLength is exceeded, a 403 is generated. But in the case of the /ActiveSync virtual, the <serverRuntime> UploadReadAhead value seems to trump this, and will generate a 413. UploadReadAhead is set to 48k by default. Increasing this value allowed successively larger EAS transactions to occur. MS warns that changing this value is a potential DoS vector, so they intentionally kept it low. While mobile users don't typically *create* large messages that will hit this limit, it is not uncommon to add to already-large discussions or forward a large attachment originated by someone else, necessitating a bump. --bill On Aug 18, 2013, at 6:07 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > On 19/08/2013 4:26 a.m., Bill Houle wrote: >> Thanks Amos, perfectly targeted. Now I guess I'll be taking my troubles off the Squid list. The output clearly shows that it is IIS that is returning the 413. The HLB is not IIS, so obviously it is coming from the Exchange/CAS level. But if anyone can hazard a guess why the CAS might be inclined to behave when not proxied but reject under Squid, I'm all ears... > > Ar. Okay your Squid is too old to log the request headers being received and sent by Squid. Are you able to upgrade to the 3.3 RPM provided by Eliezer? > http://wiki.squid-cache.org/KnowledgeBase/CentOS > > "debug_options 11,2" with that newer version will dump you out a full trace of the HTTP request and reply on both connections. > > Amos >
