Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of clinton.campbell@gmail.com
 designates 209.85.160.45 as permitted sender)
Date: Sun, 1 Jul 2012 00:40:07 -0700
From: "Clinton J. Campbell" <clinton.campbell@gmail.com>
To: users@httpd.apache.org
Message-ID: <98DF8BB87506432ABBEF1B4835177F98@gmail.com>
In-Reply-To: <4FEDDD14.9090501@primary.net>
References: <BFB00709338D4D8CAAF3225E2482CC4D@gmail.com>
 <CAAKASGwasg+mOAbnWgJEHXQpW0R3M1tiy53zTiLuisPf0f9oWA@mail.gmail.com>
 <F2D4387536FD486AA3EB7AE25D2278CA@gmail.com>
 <4FEDDD14.9090501@primary.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: Re: [users@httpd] Apache modifies URL when offloading SSL

Thanks for the tip Daniel.  I ran some more tests while monitoring httpd logs followed by a similar set of tests monitoring the Squid logs with debugging turned on.  What I've found is that the connection is initially handled correctly until credentials are posted.  At this point, httpd sends an HTTP 303 pointing to the modified URI.

- From browser to squid, the connection is https.  The URI in the initial HTTP request is https://www.mydomain.com/administrator.
- From squid to httpd, the connection is http.  The URI passed in the HTTP request is still https://www.mydomain.com/administrator/index.php.  
- Httpd responds correctly to the request returning the login page.  Squid passes the result back to the browser.
- User enters credentials, browser POST to squid.  Squid reviews the request, forwards to httpd.
- Httpd replies with HTTP 303, Location: http://www.mydomain.com/administrator/index.php.
- Squid forwards reply to browser, which now connects to squid via http.  Connection fails per policy.

I know that this is not an unusual combo, fronting an unencrypted httpd with a proxy accepting connections over https, and the server seems to handle receiving https URI's within headers for GET requests.  So I guess I'm still curious whether there is a way to configure httpd to prevent the redirection to http on the POST?

There's one remaining twist in the logs, that also makes me wonder if the problem is coming from Joomla.  I ran a scenario lifting the restriction to https and I connected unencrypted to the server.  After the POST, the server responds in the same fashion, with an HTTP 303.  Is this a standard pattern for httpd with POST requests or is it something that is likely being triggered by the application?

Appreciate the help!
Clinton


On Friday, June 29, 2012 at 9:51 AM, Daniel Ruggeri wrote:

> On 6/29/2012 11:43 AM, Clinton J. Campbell wrote:
> > I'm trying to configure the logs so that I can confirm whether this is generated by Apache or not. Any tips?
> 
> 
> 
> mod_dumpio is the place to be for debugging this kind of stuff. All
> input and output will get logged to show you exactly what httpd is
> reading and writing.
> 
> -- 
> Daniel Ruggeri
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org (mailto:users-unsubscribe@httpd.apache.org)
> For additional commands, e-mail: users-help@httpd.apache.org (mailto:users-help@httpd.apache.org)


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org