On 12/09/2015 05:19 PM, William A Rowe Jr wrote:
The "handler phase" is simply the establishment of a bidirectional
WebSocket connection. If the client did something pathological like
sending a request body with their GET request, I think that needs to
go into the bit bucket before the upgrade completes.
If that is permissible under the websocket API, then fine.
There's no mention of it either way. I think most people forget that GET
requests can have (useless?) bodies, anyway.
_If_ all the other protocols worked like WebSocket and required
authnz before an upgrade could succeed, it wouldn't make sense for
each upgrade handler to have to do the authnz check themselves. But
in this case, WebSocket is different enough that I think it will
probably have to.
No, because we will simply give you two chances to accept and trigger
the upgrade, once in the post_read_request, another in ap_invoke_handler
phase before filters are inserted.
Here you make it sound as if I won't have to duplicate the authnz checks
in the handler phase, but in a previous email you said
websocket can ignore the Upgrade: websocket offer after inspecting authnz
Did I misunderstand? I feel like I'm missing something crucial to your
point.
But you are painting all the other protocols into a corner. TLS will resume
the http/1 request on the same thread.
Cool, that answers my question then ("Are there any cases where, after a
successful upgrade, we would not want to close the connection upon
returning from the protocol handler?"). If TLS is able to switch the
filters around and have the stack continue as normal, then that sounds
like a good reason not to do what I was suggesting. ;D
the h2c or websocket protocol marks
the connection: close (or already closed/eof, depending) which prevents
the original http/1 handler from treating the connection as a keep-alive
connection. In the websocket case, I expect you can do that as step #1
in the protocol handler to address any paranoia about falling back into the
request processing cycle.
Sounds reasonable.
I'd certainly like to see a websocket prototype
or outline before we declare the protocol baked for the second time :)
Working on it. :) My original experimental hook for 2.4.17 rebased
nicely onto 2.4.18, but mod_websocket has been refactored significantly
since I wrote that and I couldn't reuse my work. Sorry I've been slow in
actual code-writing; I've been under the weather this week.
--Jacob
