httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <>
Subject Re: blocking Upgrade
Date Tue, 29 Mar 2011 21:34:44 GMT
On 3/29/2011 4:16 PM, Greg Stein wrote:
> Do you have an internet draft spec for some context here? Is there a
> proposal for HTTP/2.0?
> I might also argue that a directive is not the right answer here.
> Instead, I'd suggest that modules advertise their ability to consume
> protocols. If an Upgrade arrives, and a relevant module is found, then
> the request is handled. If no such module is found, then the Upgrade
> header is ignored, and nothing happens.˛˛
> If a module or CGI sees the Upgrade header, then what is the problem?
> It cannot truly alter the protocol in effect for the connection. That
> seems to be something only possible to handle within the core (to
> change the connection handler).
> And back to the "AllowUpgrade" directive. What the heck should it do
> if something is present *besides* "none". It isn't like that can be
> handled. Some code must be written to provide other protocols, and
> *that* code should manage the tokens recognized. Not a directive.

Agreed, we already have a single example case; in the presence of the
'SSLEngine optional' directive, which consumes the Upgrade: TLS/1.0
given Connection: Upgrade

All such handlers must respond with a 101 Switching Protocols.

So if we don't see the resulting Upgrade: TLS/1.0, HTTP/1.1 response
header, we can easily short circuit any further response in the core
handler.  The mechanics of this could be simplified, but I'd suggest
we start by stealing code from mod_ssl's upgrade handler.

The only remaining system administration decision is "allow or refuse
unrecognized Upgrade requests?"  The recognition of specific upgrade
headers is up to the installed modules and their specific configurations.

View raw message