On Mar 29, 2011 5:35 PM, "William A. Rowe Jr." <wr...@rowe-clan.net> wrote: > > 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.
Note that the client-sent Upgrade header can be completely disregarded by the server: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.42 I'm not sure that we have anything mandatory to do here. I think the correct answer is to provide connection-layer protocol handling pass-offs. I don't see how a directive assists here. Cheers, -g
