Well, I thought this one would be easy to spot but it's not. There's nothing I can do here to reproduce the reported behavior.
I wrote a Perl script client that sends your EXACT ( Palm Treo ) OPTIONS request as you had it documented in the last email. I also wrote a simple Perl Server to imitate the IIS Server and it always sends back your same exact IIS response as documented including HTTP/1.1 indicator and NO 'Connection:' header on the response. ( Sic: Keep-alive can/should be assumed ). I fed it all through Apache 2.2.8 running mod_proxy. The capture results from point to point all look identical to yours except for one thing... the behavior is correct at all times. In my testing... mod_proxy always does the RIGHT thing and, in the absence of any 'Connection:' header at all on the response from the upstream (IIS) Server, it dutifully adds the right 'Keep-Alive:' and 'Connection: Keep-Alive" headers to the response being returned to the client because at all times the default HTTP level here is 1.1 and 'Keep-Alive' can/should be assumed unless told otherwise. There was nothing I could do to make mod_proxy add 'Connection: close' to the response headed back to the client ( which is the behavior you are seeing ) unless I actually forced a 'Connection: close' header to be returned from the upstream (IIS) Server. Every time there is no 'Connection:' header at all seen on the IIS response, mod_proxy stays in 'Keep-Alive', as it should. I was testing using Apache 2.2.8 ( Stable ) version. I doubt this is all some strange behavior that is only appearing in 2.2.9 on trunk and is not evident in 2.2.8 but I suppose it's possible. The only thing that seemed to make sense for your situation after this testing was the thought that maybe, somehow, you have accidentally set the 'proxy-nokeepalive' runtime flag to TRUE and that is what is causing the 'Connection: close' header to be inserted regardless of the 'Keep-Alive' requests. So I tested that as well. * SetEnv proxy-nokeepalive 1 If I add 'SetEnv proxy-nokeepalive 1' to the httpd.conf file then mod_proxy does, in fact, change the original 'Connection: Keep-Alive' in the initial request to 'Connection: close' when it forwards the request to the upstream ( IIS ) Server. In this case, any normal upstream Server would see the 'Connection: close' coming from mod_proxy and SHOULD add it's own 'Connection: close' header to the response and close the connection after fulfilling the OPTIONS request, but just for gags I sent back the same 'No Connection header at all' response to the new OPTIONS request being changed to 'Connection: close' via mod_proxy's 'proxy-nokeepalive' option. Oddly enough... mod_proxy then reverts to assuming the response to the client should be 'Keep-Alive' even though the 'proxy-nokeepalive' flag is in effect. This appears to be a bug unto itself but still doesn't reproduce your situation ( even though it SHOULD ???? ). Again... even when using the 'proxy-nokeepalive' option, the only way I could get mod_proxy to send back 'Connection: close' in its response to the original request is to manually insert 'Connection: close' into the response coming back from the upstream (IIS) Server. The only way this would not be a (new?) bug is if the 'proxy-nokeepalive' flag is supposed to ONLY be in effect for requests that mod_proxy makes to the upstream Server but is NOT supposed to hamper it's ability to maintain 'Keep-Alive' with the original client. I don't think that was the intent of the 'proxy-nokeepalive' flag but that's the behavior I am seeing when no 'Connection: close' header comes from the upstream Server but HTTP Protocol value is still HTTP/1.1. * SetEnv force-proxy-request-1.0 1 This option also has no effect on your situation but there is some potentially odd behavior appearing when this flag is used which may or may not be YAB. If this option is ON, then mod_proxy does, in fact, dutifully change the original HTTP/1.1 level in the original client OPTIONS request to HTTP/1.0 when it forwards the request to the upstream (IIS) Server. However... it does NOT automatically add 'Connection: close' to same upstream request ( Not sure whether it's supposed to or not since HTTP/1.0 level does not automatically preclude the use of ?Keep-Alive but it definitely does NOT add 'Connection: close' .) Oddly enough, though, it always REMOVES the original 'Connection: Keep-Alive' header but forwards the new HTTP/1.0 request upstream with no 'Connection:' header at all. This is true even if you ALSO have the 'proxy-nokeepalive' option set to 'on' in conjunction with 'force-proxy-request-1.0'. The only time you actually get a 'Connection: close' header being forwarded to the upstream header is if you use 'proxy-nokeepalive' option WITHOUT also using 'force-proxy-request-1.0'. The moment 'force-proxy-request-1.0' is in effect it cancels out the behavior of 'proxy-nokeepalive' and you always get requests being forwarded upstream with no 'Connection:' header whatsoever. * WHAT NEXT? My only suggestion at this point is to try and isolate where that 'Connection: close' is actually coming from. I can't do it here. Maybe someone else could. I have a feeling you have other components in play here and one of them might be the culprit that is always adding the 'Connection: close' to the OPTIONS request. Some home-grown and/or commercial filter or something? Another ( invisible/broken ) Proxy in the mix that's automatically adding the 'Connection: close'???? Some brain-dead Mobile Gateway, maybe? Have you tried this with a totally CLEAN install of Apache + mod_proxy sitting between your client and the IIS Server onthe same MACHINE, with no other modules or filters loaded other than mod_proxy? If a CLEAN install shows correct behavior then as you add any other components into the mix you might discover which one causes a CHANGE in the default behavior I am seeing. Keep in mind, however, that you are still dealing with a brain-dead CLIENT and as long as it never responds correctly to that 'Connection: close' directive ( regardless of where it's actually coming from ) you will continue to see all kinds of weird things happening down on the Treo. Good hunting. Yours Kevin Kiley -----Original Message----- From: Ray Van Dolson <[EMAIL PROTECTED]> To: dev@httpd.apache.org Sent: Wed, 28 May 2008 5:13 pm Subject: Re: Palm Treo access to OWA via Apache 2.2.x Proxy Late reply on this -- I had to spend time on other projects. :) I have a dedicated test proxy set up now so it's easier to capture the correct packets now and experiment. > Sounds you are just stuck in the middle trying to deal with a broken > client. I thought you might be trying to actually implement the > client software or something. Yes, sorry, I should have clarified that earlier. > Sure, you can fix this. > > Just get in with a monkey wrench if you have to and force mod_proxy > to honor 'Keep-Alive' for an OPTIONS request and the behavior should > then be identical to the ( known good ) direct-to-IIS example. I am going to definitely try to do this now. Point me in the right direction maybe? Is there actually an Apache config option I can leverage for this or do I need to look to patch the mod_proxy source? > PS: Still just curious. What is the HTTP/x.x value actually being > sent by the "The Treo" for the exchange in question?. Is it the older > HTTP/1.0 or is it actually requesting full HTTP/1.1 functionality? > Sometimes that comes into play with this 'Keep-Alive' stuff. If it's > sending HTTP/1.0 then perhaps mod_proxy is simply obeying strict > standards and that's why it changes 'Keep-Alive' back to 'Close'. > 'Keep-Alive' was not 'officially' part of the HTTP/1.0 specs. It just > sort of 'crept in there' and was available BEFORE full implementation > of HTTP/1.1. So there's still a lot of confusion out there and a lot > of 'looking the other way' going on with regards to 'Keep-Alive'. > Some code tries to be strict ( Apache, generally ) and others are > 'loose' ( Microsoft/IIS? ). > > Example: MS Internet Explorer has always had an 'Advanced Option' > which allows you to decide to use HTTP/1.1 for "Proxy Connections" > but it is OFF by default. Default behavior for MSIE Proxy requests is > to use the older HTTP/1.0. However... that doesn't mean it won't use > "Keep-Alive". It treats that part of the HTTP/1.1 spec as an > exception. > > Apologies in advance if this is all just old news to you. > > On my own Microsft Windows Mobile Treo, however, this legacy > "Advanced Option" is missing. The Pocket Internet Explorer Browser > under Windows Mobile will ALWAYS send an HTTP/1.1 request. It is requesting HTTP/1.1. I'll paste the full conversation here which I just captured. This is from the Treo to and from the Proxy and again is with Apache 2.2.9 svn 659141 straight HTTP (no SSL). 1 OPTIONS /Microsoft-Server-ActiveSync HTTP/1.1 MS-ASProtocolVersion: 2.5 Connection: Keep-Alive User-Agent: PalmOne-TreoAce/1.53 Host:redowadev.esri.com Cache-Control: no-cache Authorization: Basic <stuff> Content-Length: 0 4 HTTP/1.1 200 OK Date: Wed, 28 May 2008 22:52:00 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 2.0.50727 Public: OPTIONS, POST Allow: OPTIONS, POST MS-Server-ActiveSync: 6.5.7638.1 MS-ASProtocolVersions: 1.0,2.0,2.1,2.5 MS-ASProtocolCommands: Sync,SendMail,SmartForward,SmartReply,GetAttachment,GetHierarchy,CreateCollection,DeleteCollection,MoveCollection,FolderSync,FolderCreate,FolderDelete,FolderUpdate,MoveItems,GetItemEstimate,MeetingResponse,ResolveRecipients,ValidateCert,Provision,Search,Notify,Ping Content-Length: 0 Cache-Control: private Content-Type: text/html; charset=UTF-8 Connection: close 5 POST /Microsoft-Server-ActiveSync?Cmd=FolderSync&[EMAIL PROTECTED]&DeviceId=xxXXXXxxxx63&DeviceType=PalmOneTreoAce HTTP/1.1 Content-Type: application/vnd.ms-sync.wbxml MS-ASProtocolVersion: 2.5 Connection: Keep-Alive User-Agent: PalmOne-TreoAce/1.53 Host:redowadev.esri.com Cache-Control: no-cache X-MS-PolicyKey: 0 Authorization: Basic <stuff> Content-Length: 13 ^^ This packet is never proxied on to the IIS server. Here is the proxy to OWA (IIS) server conversation: 2 OPTIONS /Microsoft-Server-ActiveSync HTTP/1.1 Host: redowadev.esri.com MS-ASProtocolVersion: 2.5 User-Agent: PalmOne-TreoAce/1.53 Cache-Control: no-cache Authorization: Basic <stuff> X-Forwarded-For: 99.204.225.107 X-Forwarded-Host: redowadev.esri.com X-Forwarded-Server: redowadev.esri.com Connection: Keep-Alive Content-Length: 0 3 HTTP/1.1 200 OK Date: Wed, 28 May 2008 22:52:00 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 2.0.50727 Public: OPTIONS, POST Allow: OPTIONS, POST MS-Server-ActiveSync: 6.5.7638.1 MS-ASProtocolVersions: 1.0,2.0,2.1,2.5 MS-ASProtocolCommands: Sync,SendMail,SmartForward,SmartReply,GetAttachment,GetHierarchy,CreateCollection,DeleteCollection,MoveCollection,FolderSync,FolderCreate,FolderDelete,FolderUpdate,MoveItems,GetItemEstimate,MeetingResponse,ResolveRecipients,ValidateCert,Provision,Search,Notify,Ping Content-Length: 0 Cache-Control: private Content-Type: text/html ^^ IIS agrees to keep the connection alive. FWIW, this Treo doesn't appear to have too much in the way of advanced options to toggle how its HTTP client used in sync'ing behaves. Thanks again, Ray
