httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Champion <>
Subject Re: Upgrade Summary
Date Thu, 10 Dec 2015 03:22:03 GMT
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 

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


View raw message