On Mar 29, 2011, at 11:16 PM, Greg Stein wrote:

> Do you have an internet draft spec for some context here? Is there a
> proposal for HTTP/2.0?

websockets

> 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.

Right, I woke up thinking the same thing -- that the http filter
is the only place that an Upgrade could actually be implemented
because it would have to switch itself off.  What I was trying
to avoid is a script thinking that it can switch without writing
a new protocol filter, or a CGI that deliberately spoofs an upgrade
for some nefarious purpose I haven't thought of yet.

We can just delete the Upgrade header in the http_filter, for now.

....Roy

Reply via email to