Re: mod_proxy race condition bug #37770
On 05/21/2008 10:34 PM, Adam Woodworth wrote: I think there is a problem with r657443 (and thus I assume r645813): I applied the r657443 patch to my copy of the 2.2.8 official release source and it doesn't work right. The problem is that the change to mod_proxy_http.c checks c-keepalives for a value, but c-keepalives is filled out by ap_http_header_filter(), which isn't called until later. So, c-keepalives is always 0 at this point. Which also means No, it is not always 0 at this point. It has a different value once the connection to the client is not used for the first time. that the number of keepalives message in the ap_log_rerror() msg isn't going to mean anything, but at this point it never reaches it. Also, I patched the patch to manually set c-keepalives to 1 for testing so that I could test out this r657443 patch. However, what happened was that Apache would kick back an error page to the client, instead of just closing the connection. So, no improvement. Has this patch been tested and verified anywhere? Yes, with the test code I posted here on list. Regards Rüdiger
Re: Palm Treo access to OWA via Apache 2.2.x Proxy
On 05/22/2008 03:05 AM, Ray Van Dolson wrote: I'm having a heck of a time getting Palm Treo's to work through our Apache 2.2.3 based proxy talking to an OWA2K7 setup running on IIS. I believe I may be getting pinched by: https://issues.apache.org/bugzilla/show_bug.cgi?id=43238 The Treo seems to work fine without a proxy. I observe the following (no proxy): 1 TREO Sends OPTIONS request to IIS (Connection: Keep-Alive) 2 IISReplies with 200 OK (No Connection header) 3 TREO Sends POST /Microsoft-Server-ActiveSync... (Connection: Keep-Alive) 4 IISReplies with 200 OK + payload (No Connection header) As I said, everything works fine this way. With mod_proxy in the mix however: 1 TREO Sends OPTIONS request to Apache (Connection: Keep-Alive) 2 Apache Sends OPTIONS request to IIS (Connection: Close) 3 IISReplies with 200 OK (Connection: Close) 4 Apache Sends 200 OK back to Treo (Connection: Close) 5 Apache Sends SSLv3 Close Notify to Treo 6 Apache Sends FIN,ACK to Treo 7 TREO Sends POST /Microsoft-Server-ActiveSync... (Connection: Keep-Alive) 8 Apache Sends ACK to Treo 9 Apache Sends Dup ACK to Treo 10 Apache Sends Dup ACK to Treo Timeout... First, please try using Apache 2.2.8 plus patches. There have been numerous changes to the proxy code between 2.2.8 and 2.2.3. Second, is the above behaviour with or without the patch from PR43238? Third, please post your proxy configuration. Regards Rüdiger
Re: Empty Reason Phrase (BZ 44995/45092)
On Tue, May 20, 2008 at 3:27 PM, Ruediger Pluem [EMAIL PROTECTED] wrote: On 05/20/2008 08:52 PM, Jeff Trawick wrote: Do we really need to require the space in the case that the reason phrase is empty? No... Both sets of code should be changed to consider the space optional. We just need to make sure we generate the space in our response so some other software doesn't have to be so generous.
Re: Palm Treo access to OWA via Apache 2.2.x Proxy
On Thu, May 22, 2008 at 01:32:25AM -0700, Ruediger Pluem wrote: On 05/22/2008 03:05 AM, Ray Van Dolson wrote: I'm having a heck of a time getting Palm Treo's to work through our Apache 2.2.3 based proxy talking to an OWA2K7 setup running on IIS. I believe I may be getting pinched by: https://issues.apache.org/bugzilla/show_bug.cgi?id=43238 The Treo seems to work fine without a proxy. I observe the following (no proxy): 1 TREO Sends OPTIONS request to IIS (Connection: Keep-Alive) 2 IISReplies with 200 OK (No Connection header) 3 TREO Sends POST /Microsoft-Server-ActiveSync... (Connection: Keep-Alive) 4 IISReplies with 200 OK + payload (No Connection header) As I said, everything works fine this way. With mod_proxy in the mix however: 1 TREO Sends OPTIONS request to Apache (Connection: Keep-Alive) 2 Apache Sends OPTIONS request to IIS (Connection: Close) 3 IISReplies with 200 OK (Connection: Close) 4 Apache Sends 200 OK back to Treo (Connection: Close) 5 Apache Sends SSLv3 Close Notify to Treo 6 Apache Sends FIN,ACK to Treo 7 TREO Sends POST /Microsoft-Server-ActiveSync... (Connection: Keep-Alive) 8 Apache Sends ACK to Treo 9 Apache Sends Dup ACK to Treo 10 Apache Sends Dup ACK to Treo Timeout... First, please try using Apache 2.2.8 plus patches. There have been numerous changes to the proxy code between 2.2.8 and 2.2.3. I figured as much and will do that today. Second, is the above behaviour with or without the patch from PR43238? It is with -- sort of. I took the changes to the files and backported them into the RHEL5 Apache 2.2.3 RPM. It compiled, but based on the behavior I'm seeing, I'm not sure if it's working correctly. Going 2.2.8 is probably the better option. Third, please post your proxy configuration. See: https://redowa.esri.com/owa.conf.include Notes: - SSLProxyProtocol is set to SSLv3 only so I can more easily decrypt packets with wireshark (TLSv1 decrypt seems hit and miss) - I have disabled mod_security for testing (though you see references to it) Thanks in advance. Ray
2.2.9 status
Right now, we are waiting on an APR release before we can release 2.2.9... Does matter if we go with APR 1.3.0 or 1.2.x, we need a release (showstopper related to 1.2)
Re: 2.2.9 status
Jim Jagielski wrote: Right now, we are waiting on an APR release before we can release 2.2.9... Does matter if we go with APR 1.3.0 or 1.2.x, we need a release (showstopper related to 1.2) APR_EDONTCARE, although the community was very vocal in preferring to put APR 1.3.0 to bed already, once Roy's concerns about the nonsense created by --with-static-support is addressed. Showstopper to Windows 2008 (a server OS) is the STATUS entry about the ApacheMonitor.c sources I would very much like to migrate back to the 2.2.x branch already, now that it supports the new UAC schema. (As I note, this improves things for other 200x users who prefer not to use an administrator login, but who want access to the monitor).
Re: Palm Treo access to OWA via Apache 2.2.x Proxy
On Thu, May 22, 2008 at 08:53:41AM -0700, Ray Van Dolson wrote: On Thu, May 22, 2008 at 01:32:25AM -0700, Ruediger Pluem wrote: On 05/22/2008 03:05 AM, Ray Van Dolson wrote: I'm having a heck of a time getting Palm Treo's to work through our Apache 2.2.3 based proxy talking to an OWA2K7 setup running on IIS. I believe I may be getting pinched by: https://issues.apache.org/bugzilla/show_bug.cgi?id=43238 The Treo seems to work fine without a proxy. I observe the following (no proxy): 1 TREO Sends OPTIONS request to IIS (Connection: Keep-Alive) 2 IISReplies with 200 OK (No Connection header) 3 TREO Sends POST /Microsoft-Server-ActiveSync... (Connection: Keep-Alive) 4 IISReplies with 200 OK + payload (No Connection header) As I said, everything works fine this way. With mod_proxy in the mix however: 1 TREO Sends OPTIONS request to Apache (Connection: Keep-Alive) 2 Apache Sends OPTIONS request to IIS (Connection: Close) 3 IISReplies with 200 OK (Connection: Close) 4 Apache Sends 200 OK back to Treo (Connection: Close) 5 Apache Sends SSLv3 Close Notify to Treo 6 Apache Sends FIN,ACK to Treo 7 TREO Sends POST /Microsoft-Server-ActiveSync... (Connection: Keep-Alive) 8 Apache Sends ACK to Treo 9 Apache Sends Dup ACK to Treo 10 Apache Sends Dup ACK to Treo Timeout... First, please try using Apache 2.2.8 plus patches. There have been numerous changes to the proxy code between 2.2.8 and 2.2.3. I figured as much and will do that today. I'm running the latest svn version from the 2.2.x branch (659141 when I compiled). The Treo still doesn't work. I see similar behavior to that of the above. I could open a bz bug for this and include tcpdumps (can the bugs be tagged private?) Note that my compile is against the RHEL5 version of apr and apr-util (1.2.7 I believe). Would this impact anything? I still wonder why Apache is sending the Connection: Close header in #2 above. IIS doesn't do this (and the Treo works direct there). Appreciate any insight. Ray
Re: Palm Treo access to OWA via Apache 2.2.x Proxy
On May 21, 2008, at 9:05 PM, Ray Van Dolson wrote: As I said, everything works fine this way. With mod_proxy in the mix however: 1 TREO Sends OPTIONS request to Apache (Connection: Keep-Alive) 2 Apache Sends OPTIONS request to IIS (Connection: Close) 3 IISReplies with 200 OK (Connection: Close) 4 Apache Sends 200 OK back to Treo (Connection: Close) 5 Apache Sends SSLv3 Close Notify to Treo 6 Apache Sends FIN,ACK to Treo 7 TREO Sends POST /Microsoft-Server-ActiveSync... (Connection: Keep-Alive) 8 Apache Sends ACK to Treo 9 Apache Sends Dup ACK to Treo 10 Apache Sends Dup ACK to Treo Timeout... I attempted to backport the patches mentioned here: http://svn.apache.org/viewvc?view=revrevision=657440 In the hopes it might address this, but I'm still seeing the connection prematurely closed around #5, #6 above. I *believe* this is the cause of my issue but am not positive. The Treo continues to try and use an existing connection that no longer exists, and Apache keeps sending Connection: close headers. I don't see how this is a bug. Why does the TREO not close the socket and reopen another? How is it premature? The server can decide to say That's enough at any time and the client must honor that. Instead, it looks like the TREO is seeing 'Connection: close' and ignoring it and considering the connection persistent. This is all made trickier by SSL being in used end to end and Wireshark not consistently decrypting packets :) Any thoughts or advice? I feel if I can just get Apache to quit forcing the Connection: close headers in there this would work. Ray
Re: mod_proxy race condition bug #37770
Ok my mistake, the setup I was using turned out to be the problem. I'm now able to see the patch working. Sorry about that. Thanks again Ruediger. Now I just have to modify our mod_perl application to behave correctly when mod_proxy sends EOC. Adam On Thu, May 22, 2008 at 4:28 AM, Ruediger Pluem [EMAIL PROTECTED] wrote: On 05/21/2008 10:34 PM, Adam Woodworth wrote: I think there is a problem with r657443 (and thus I assume r645813): I applied the r657443 patch to my copy of the 2.2.8 official release source and it doesn't work right. The problem is that the change to mod_proxy_http.c checks c-keepalives for a value, but c-keepalives is filled out by ap_http_header_filter(), which isn't called until later. So, c-keepalives is always 0 at this point. Which also means No, it is not always 0 at this point. It has a different value once the connection to the client is not used for the first time. that the number of keepalives message in the ap_log_rerror() msg isn't going to mean anything, but at this point it never reaches it. Also, I patched the patch to manually set c-keepalives to 1 for testing so that I could test out this r657443 patch. However, what happened was that Apache would kick back an error page to the client, instead of just closing the connection. So, no improvement. Has this patch been tested and verified anywhere? Yes, with the test code I posted here on list. Regards Rüdiger
Re: Palm Treo access to OWA via Apache 2.2.x Proxy
On Thu, May 22, 2008 at 01:52:11PM -0700, Jim Jagielski wrote: On May 21, 2008, at 9:05 PM, Ray Van Dolson wrote: As I said, everything works fine this way. With mod_proxy in the mix however: 1 TREO Sends OPTIONS request to Apache (Connection: Keep-Alive) 2 Apache Sends OPTIONS request to IIS (Connection: Close) 3 IISReplies with 200 OK (Connection: Close) 4 Apache Sends 200 OK back to Treo (Connection: Close) 5 Apache Sends SSLv3 Close Notify to Treo 6 Apache Sends FIN,ACK to Treo 7 TREO Sends POST /Microsoft-Server-ActiveSync... (Connection: Keep-Alive) 8 Apache Sends ACK to Treo 9 Apache Sends Dup ACK to Treo 10 Apache Sends Dup ACK to Treo Timeout... I attempted to backport the patches mentioned here: http://svn.apache.org/viewvc?view=revrevision=657440 In the hopes it might address this, but I'm still seeing the connection prematurely closed around #5, #6 above. I *believe* this is the cause of my issue but am not positive. The Treo continues to try and use an existing connection that no longer exists, and Apache keeps sending Connection: close headers. I don't see how this is a bug. Why does the TREO not close the socket and reopen another? How is it premature? The server can decide to say That's enough at any time and the client must honor that. Instead, it looks like the TREO is seeing 'Connection: close' and ignoring it and considering the connection persistent. Understood; I'm happy to blame the Treo for perhaps poorly implementing HTTP, but from the user perspective it works directly to IIS, but not via the Proxy. My most feasible option is to try and see if this is something that can be addressed within Apache. An option to allow a persistent connection in the scenario above might help. I promise to go and read through the RFC's, but if the Treo is requesting a Keep-Alive connection, shouldn't Apache try its best not to close the connection as quickly as it is? Ray This is all made trickier by SSL being in used end to end and Wireshark not consistently decrypting packets :) Any thoughts or advice? I feel if I can just get Apache to quit forcing the Connection: close headers in there this would work. Ray
Re: Palm Treo access to OWA via Apache 2.2.x Proxy
On Thu, May 22, 2008 at 01:59:30PM -0700, Ray Van Dolson wrote: I promise to go and read through the RFC's, but if the Treo is requesting a Keep-Alive connection, shouldn't Apache try its best not to close the connection as quickly as it is? It doesn't matter though. If the server is saying Connection closed, the client shouldn't just ignore it. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ Great is the guilt of an unnecessary war ~ John Adams
Re: Palm Treo access to OWA via Apache 2.2.x Proxy
On Thu, May 22, 2008 at 02:59:41PM -0700, Jim Jagielski wrote: On Thu, May 22, 2008 at 01:59:30PM -0700, Ray Van Dolson wrote: I promise to go and read through the RFC's, but if the Treo is requesting a Keep-Alive connection, shouldn't Apache try its best not to close the connection as quickly as it is? It doesn't matter though. If the server is saying Connection closed, the client shouldn't just ignore it. I am not disagreeing with this. The likelihood of getting all Treo devices fixed to act correctly however is right near 0% :) Ray
Re: Palm Treo access to OWA via Apache 2.2.x Proxy
On Thu, May 22, 2008 at 4:59 PM, Ray Van Dolson [EMAIL PROTECTED] wrote: On Thu, May 22, 2008 at 01:52:11PM -0700, Jim Jagielski wrote: On May 21, 2008, at 9:05 PM, Ray Van Dolson wrote: As I said, everything works fine this way. With mod_proxy in the mix however: 1 TREO Sends OPTIONS request to Apache (Connection: Keep-Alive) 2 Apache Sends OPTIONS request to IIS (Connection: Close) 3 IISReplies with 200 OK (Connection: Close) 4 Apache Sends 200 OK back to Treo (Connection: Close) 5 Apache Sends SSLv3 Close Notify to Treo 6 Apache Sends FIN,ACK to Treo 7 TREO Sends POST /Microsoft-Server-ActiveSync... (Connection: Keep-Alive) 8 Apache Sends ACK to Treo 9 Apache Sends Dup ACK to Treo 10 Apache Sends Dup ACK to Treo Timeout... I attempted to backport the patches mentioned here: http://svn.apache.org/viewvc?view=revrevision=657440 In the hopes it might address this, but I'm still seeing the connection prematurely closed around #5, #6 above. I *believe* this is the cause of my issue but am not positive. The Treo continues to try and use an existing connection that no longer exists, and Apache keeps sending Connection: close headers. I don't see how this is a bug. Why does the TREO not close the socket and reopen another? How is it premature? The server can decide to say That's enough at any time and the client must honor that. Instead, it looks like the TREO is seeing 'Connection: close' and ignoring it and considering the connection persistent. Understood; I'm happy to blame the Treo for perhaps poorly implementing HTTP, but from the user perspective it works directly to IIS, but not via the Proxy. My most feasible option is to try and see if this is something that can be addressed within Apache. An option to allow a persistent connection in the scenario above might help. Try to get the Treo into different connection-handling logic altogether and see if that helps. Maybe force-response-1.0 will do it. (http://httpd.apache.org/docs/2.2/env.html#special) I promise to go and read through the RFC's, but if the Treo is requesting a Keep-Alive connection, shouldn't Apache try its best not to close the connection as quickly as it is? no ;)
Re: Palm Treo access to OWA via Apache 2.2.x Proxy
My most feasible option is to try and see if this is something that can be addressed within Apache. An option to allow a persistent connection in the scenario above might help. Try to get the Treo into different connection-handling logic altogether and see if that helps. Maybe force-response-1.0 will do it. (http://httpd.apache.org/docs/2.2/env.html#special) This doesn't appear to have worked (at least initially). I didn't do packet dumps on this yet though. I am setting up a better test environment however and will do one then. Ray
Re: 2.2.9 status
On May 22, 2008, at 11:50 AM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: Right now, we are waiting on an APR release before we can release 2.2.9... Does matter if we go with APR 1.3.0 or 1.2.x, we need a release (showstopper related to 1.2) APR_EDONTCARE, although the community was very vocal in preferring to put APR 1.3.0 to bed already, once Roy's concerns about the nonsense created by --with-static-support is addressed. Showstopper to Windows 2008 (a server OS) is the STATUS entry about the ApacheMonitor.c sources I would very much like to migrate back to the 2.2.x branch already, now that it supports the new UAC schema. (As I note, this improves things for other 200x users who prefer not to use an administrator login, but who want access to the monitor). Go ahead and migrate them. I looked at the patch last week and found no clue as to how to evaluate it without a working win32 install. You are the only windows developer on trunk, so let's just treat anything specific to win32 as auto-backport until the folks who only test releases start complaining. Same goes for BeOS, if anyone cares. Roy
Re: 2.2.9 status
Roy T. Fielding wrote: Go ahead and migrate them. Happy to. I looked at the patch last week and found no clue as to how to evaluate it without a working win32 install. Understandable. I thought for a while about going the utf-8 route, but since this code would never, never be applicable anywhere else, I just gave up on the thought. You are the only windows developer on trunk, so let's just treat anything specific to win32 as auto-backport until the folks who only test releases start complaining. Same goes for BeOS, if anyone cares. Was ... welcome Tom :-) Makes sense, although I had tossed up to http://people.apache.org/~wrowe/ in hopes that one of the many users might test the new ApacheMonitor (message id [EMAIL PROTECTED]). A shame that didn't happen but agreed, no reason to let this block a release. Bill
Re: 2.2.9 status
Roy T. Fielding wrote: Go ahead and migrate them. Happy to. I looked at the patch last week and found no clue as to how to evaluate it without a working win32 install. Understandable. I thought for a while about going the utf-8 route, but since this code would never, never be applicable anywhere else, I just gave up on the thought. You are the only windows developer on trunk, so let's just treat anything specific to win32 as auto-backport until the folks who only test releases start complaining. Same goes for BeOS, if anyone cares. Was ... welcome Tom :-) Makes sense, although I had tossed up to http://people.apache.org/~wrowe/ in hopes that one of the many users might test the new ApacheMonitor (message id [EMAIL PROTECTED]). A shame that didn't happen but agreed, no reason to let this block a release. It works on XP and Vista, what more do you need? Gav... Bill
Re: 2.2.9 status
[EMAIL PROTECTED] wrote: It works on XP and Vista, what more do you need? Someone to independently confirm - thanks Gav :)
Re: 2.2.9 status
Was a solution ever arrived at for proper handling of %3B (escaped ';') in URLs passed to Tomcat via mod_proxy_ajp? This and 8K AJP packet handling are sorely missing in mod_proxy_ajp. -- Jess Holle
Re: Palm Treo access to OWA via Apache 2.2.x Proxy
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? 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. -Original Message- From: Ray Van Dolson [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Thu, 22 May 2008 5:24 pm Subject: Re: Palm Treo access to OWA via Apache 2.2.x Proxy On Thu, May 22, 2008 at 02:59:41PM -0700, Jim Jagielski wrote: On Thu, May 22, 2008 at 01:59:30PM -0700, Ray Van Dolson wrote: I promise to go and read through the RFC's, but if the Treo is requesting a Keep-Alive connection, shouldn't Apache try its best not to close the connection as quickly as it is? It doesn't matter though. If the server is saying Connection closed, the client shouldn't just ignore it. I am not disagreeing with this. The likelihood of getting all Treo devices fixed to act correctly however is right near 0% :) Ray
Re: 2.2.9 status
William A. Rowe, Jr. wrote: [EMAIL PROTECTED] wrote: It works on XP and Vista, what more do you need? Someone to independently confirm - thanks Gav :) I tested your ApacheMonitor.exe.r652599 and ApacheMonitorU.exe.r652599 from http://people.apache.org/~wrowe on Win2k, XP, Vista. Also built it from today's trunk with VC9 and re-tested on all three (both UNICODE MBCS builds). No problems on win2k or XP. It prompts re-invokes (once, as expected) as an administrator on Vista with UAC turned on. Sorry, I didn't try the Unicode version on any non-western-latin language systems; but it's definitely calling the 'W'ide-character flavor of Advapi32 Shell32 functions, so there's not much that could go awry. -tom-
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
Re: Palm Treo access to OWA via Apache 2.2.x Proxy
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: dev@httpd.apache.org 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
