Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Fri, 30 May 2008 08:08:55 -0700
From: Ray Van Dolson <rvandolson@esri.com>
To: dev@httpd.apache.org
Subject: Re: Palm Treo access to OWA via Apache 2.2.x Proxy
Message-ID: <20080530150855.GA24965@esri.com>
References: <20080522215941.GA35718@devsys.jaguNET.com>
 <20080522222424.GA17945@esri.com>
 <8CA8AA114407E7A-14B0-15BB@webmail-de04.sysops.aol.com>
 <20080523045030.GA22710@esri.com>
 <8CA8AABF4E46C9A-14B0-16EE@webmail-de04.sysops.aol.com>
 <20080528231307.GA383@esri.com>
 <8CA8F74E07CE248-EE4-1DD9@MBLK-M27.sysops.aol.com>
 <20080529135636.GA9890@esri.com> <20080529171735.GA12245@esri.com>
 <8CA900503AB874B-1174-344F@mblk-d27.sysops.aol.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8CA900503AB874B-1174-344F@mblk-d27.sysops.aol.com>
User-Agent: Mutt/1.5.17 (2007-11-01)

> Nope.
> 
> My test client is a Perl SOCKET level IO deal and I am able
> to send EXACTLY what was in your email as the 'fake' Treo
> request, including the 'messed up' Host:redowadev.esri.com
> header which is missing the SPACE character after the colon.
> 
> Doesn't make any difference here.
> 
> Apache parses the 'Host:' header with no problems and, as you
> said, corrects the header when it forwards it upstream, but
> the original 'fixing' of the inbound header appears to have
> nothing to do with any decision making with regards to
> 'Connection: close'.
> 
> It's still a total mystery where that 'Connection: close'
> is actually coming from and I still cannot make it happen.

Ah, interesting.  So much for that theory...

> Glad you have a working solution but
> something tells me this isn't over yet.
> 
> Still curious about who/what is/was adding that
> 'Connection: close' and why.
> 
> If it starts appearing again give a shout.
> 

Well, this is definitely still something I can reproduce easily (just
have to remove the RequestHeader directive), and I have a test server
where it's easy to troubleshoot.

I would *love* to step through this with gdb -- anyone out there a gdb
expert enough to tell me how to "capture" a bit of runtime and play it
back later so I can step through the source after the fact?  Doing it
in real time seems to not give consistent results.

Maybe oprofile would do the trick for me... seems like there should be
a way for gdb to "capture" the session though if its attached... I'll
dig into that sometime unless someone can give me a pointer off the top
of their head :)

Thanks,
Ray