Stefan,
On 09/21/2015 05:00 AM, Stefan Eissing wrote:
I think a "protocol_ugprade" hook would work better. That way, a
module like yours can replace the core upgrade handling itself, send
your own 101 response and call ap_switch_protocol() yourself. Would
that work for you?
Yes, a separate upgrade hook could probably work. I'm not sure if it
makes sense to call ap_switch_protocol() from such a hook, though --
shouldn't I just perform the switch directly at that point? That way I
could prevent any other modules from cutting in and ruining the handshake.
7230 speaks and has registered "HTTP/x(.x)?" as token, but for ALPN
it is "http/1.1" (and not case-insensitive), I tend to propose that
we treat tokens in "Upgrade:" headers as case-insensitive. That would
mean:
The core upgrade handler would lower case all protocol tokens in the
Upgrade header before passing it to ap_select_protocol(). That makes
selections normalized again. If someone wants to see the original
value, it needs to look at the request headers itself.
That sounds good to me. Can anyone comment on the wisdom of making
Upgrade case-insensitive as well? Should we try to get that formalized?
1) WebSocket prefers that the server close the TCP connection
before the client [...] Is there a "proper" way to do this
on my end, or is there more architectural work that would be needed
to support server-led TCP closes?
Hmm, you should have to do nothing. The core upgrade handler marks
the connection for closing which *should* be enough. Bug?
Hm, okay. I'll try to root-cause when I get a chance.
2) Protocols is per-virtual-host, but I think typically people want
to enable WebSocket for a particular URI, not an entire server [...]
Maybe WebSocket is just an oddball protocol from Upgrade's point of
view?
Yes and no. Different from http/2 as that is another framing layer
that still has http/1.1 semantics. But also a client in HTTP/1.1
Upgrades. The mechanism we implement should work for both.
I was originally wondering if Protocols should be made per-Location, but
after having slept on it, I think it's fine to enable WebSocket per-host
and simply have the module refuse to propose a switch if the requested
URI is not WebSocket-enabled.
Not having a separate worker pool for mod_h2 is desirable. However
for 2.4.x branch, there are limits to what can be done. In trunk,
integration should happen. Currently I know not enough about mpms to
come up with a solid proposal.
That's fair; I'd definitely like to see mod_h2 in a release sooner than
later. :) I'll try to get acquainted with mpm_motorz, since I don't know
much about it either (other than "it's magic"). Maybe it'll provide some
ideas for mod_websocket at least.
--Jacob
