httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: blocking Upgrade
Date Tue, 29 Mar 2011 21:16:37 GMT
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.

Cheers,
-g

On Tue, Mar 29, 2011 at 17:04, Roy T. Fielding <fielding@gbiv.com> wrote:
> Does anyone with a working install want a quick project?
>
> We need to block the Upgrade header field by default.  What this
> will require is a new configuration command, like
>
>   AllowUpgrade None | word ...
>
> where word is any protocol name, like HTTP/2.0, waka, websocket, etc.
> The config command must only be allowed in rsrc_conf.
>
> We then need a check somewhere in the http filter for an incoming
> request header field called "Upgrade".  If present and the config option
> is set to None (or default), then remove the Upgrade field before it
> is seen by the request handler (i.e., before it might be used by some
> module or CGI script to send the server down a rat hole).
> If the config option is set and not None, then set the Upgrade
> header field-value to be the intersection of what was sent by the
> client and what is allowed by the config.
>
> Likewise, perform the same filtering on outbound responses.
>
> In other words, only allow a handler to upgrade the connection
> if it has been explicitly configured by the main server config
> to be an okay thing to do.
>
> Any takers?  If not, I'll give it a try next week when I am back
> from the IETF.
>
> ....Roy
>

Mime
View raw message