Ah... okay. Thanks for the clarification. 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.
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. However... if you have a client that just 'assumes' connections stay active just because it sent 'Connection: Keep-Alive' and isn't bothering to check the actual connection responses from Servers then this initial handshake thing is going to be the least of your worries. That's a client-side boo-boo that's going to keep jumping up and biting everyone in the buttocks and it won't hurt to point that out to whoever is responsible for that client. Good luck. 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. -----Original Message----- From: Ray Van Dolson <[EMAIL PROTECTED]> To: [email protected] Sent: Thu, 22 May 2008 11:50 pm Subject: Re: Palm Treo access to OWA via Apache 2.2.x Proxy On Thu, May 22, 2008 at 09:03:23PM -0700, [EMAIL PROTECTED] wrote: > > Your posts keep saying "The Treo does this" and the "Treo does > that" and "likelihood of fixing Treos is 0 percent"... > > ...but I'm a little confused. > > What SOFTWARE are we talking about on the "Treo". > The "Treo" is just a handheld. It does what it's told to do. > > Are you using one of the carrier's standard browsers or > is this is custom piece of software sending this intitial > OPTIONS request and then ignoring the 'Connection: Close' > from the Server? I think the latter. The web browser component of the Treo software appears to work correctly, it's just the ActiveSync portion that is failing (part of the mail application). > If it's a piece of custom software then the likelihood of > at least fixing the "Why doesn't the Treo respond correctly > to Close Connection" part of this issue is actually > around 100 percent. Just fix the client and send out > updates. > > It is NOT a 'bug' for a Proxy server to decide to send > 'Connection: Close' to an upstream server even if the > original request contains "Connection: Keep-Alive". > > It IS, however, a definite bug on the client side if a Server > sends 'Connection: Close' and the client still behaves as > if the connection is active. Believe me, I understand this. I will definitely push Palm to address this issue with whatever influence I can wield. :) However, as Apache has other environment type settings that allow overriding of behaviors for other broken clients, I was hoping to discover something similar that might do the trick here -- or that an option could even be added. Thanks for all the feedback. Ray
