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.
