httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: blocking Upgrade
Date Wed, 30 Mar 2011 00:02:04 GMT
On Mar 29, 2011 5:35 PM, "William A. Rowe Jr." <> 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:

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.


View raw message