httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From toki...@aol.com
Subject Re: Palm Treo access to OWA via Apache 2.2.x Proxy
Date Thu, 29 May 2008 07:29:35 GMT
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 <rvandolson@esri.com>
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&User=userid@esri.com&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



 


Mime
View raw message