Folks,

In situations where there is a load balancer or offload appliance that is processing SSL connections, the web server(s) see only plaintext connections come in, and when they have to generate a 301 or 302 redirect, all they know to do is include a Location: header for the protocol scheme they're running (http) and the port they're listening on (whatever that is, possibly not the same as the load balancer).

This is a problem because when a client receives this redirect from the web server, it may try reconnect to the server over plaintext instead of https, and to a port that may not even be accessible from its point of view. This is clearly a suboptimal user experience.

Some devices can fix Location: headers on the way out, but not all have this capability. And what if you don't own that load balancer box, and you can't get a meeting with the group that manages it for three weeks? Our own mod_proxy fixes Location: headers on the way out, but leaves the HTML document sent out with the redirect unchanged. Sun's new Niagara boxes have a widget called kssl that uses the cryptographic capabilities of the CPU to provide an SSL offload proxy. I don't know of its capabilities to fix these redirect issues, and would like to play with such a box.

The attached patch fixes this issue inside the httpd core. It introduces two new directives:

ExternalListenerPort portnumber
ExternalListenerScheme http|https

that are used when the server has to determine its port number and protocol scheme.

This fixes redirect issues in cases where the server is running behind a device that it doesn't know about, but which changes the listener port and/or strips off SSL encryption.

What do you, the httpd dev community, think of:

1) the concept?

2) the attached implementation?

Check out the patch and tell me what you think about it. There's even documentation! I'm also attaching some perl-framework tests; see the README in the tarball.

Thanks,

Sander

Disclosure: I work for Britestream, who market an SSL Offload Network Card that would benefit from this patch. However, I have been told by several people that this patch would solve some of their own configuration issues.

--
[EMAIL PROTECTED]              http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF

Attachment: externallistener.patch
Description: Binary data

Attachment: extlistener-test.tar.gz
Description: GNU Zip compressed data

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to