Great to see where this discussion is headed: +1 on the last design ideas.
Going with one ‘as early as possible’ upgrade and one ‘upgrade last’ should handle all these cases just fine. I don’t think the h2c and TLS cases really have to be that different as suggested in the earlier parts of the discussion. Both want to upgrade as soon as possible, which is +- after the initial request is read, and before the response is generated. TLS then really needs to exchange information both ways, while for h2c allowing exchange both ways allows doing some things a bit earlier. Websockets are different… and in some ways not really an upgrade of the connection… more like a hostile takeover with a final operation to a targetJ More like a CONNECT request to a proxy… or perhaps a PRI request to a HTTP/1.1 server that handles h2direct that way… one final request until the connection closes. Bert From: William A Rowe Jr [mailto:wr...@rowe-clan.net] Sent: donderdag 10 december 2015 07:40 To: httpd <dev@httpd.apache.org> Subject: Re: Upgrade Summary On Wed, Dec 9, 2015 at 9:22 PM, Jacob Champion <champio...@gmail.com <mailto:champio...@gmail.com> > wrote: On 12/09/2015 05:19 PM, William A Rowe Jr wrote: _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. I propose two chances to catch the upgrade, early and late. You need auth, therefore you must inspect the late catch, which follows authnz but precedes the handler invocation. If a websocket protocol module determines that authnz denied websocket but not the resource, then it can proceed to the normal http/1 handler without responding with a 101-switching protocols. But if the request meets the requirements to be handled by the websocket protocol, you reply to the Protocol API with an 'upgrade accepted' and take ownership of the request and the connection. 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. No worries, 2.4.18 is an incremental set of improvements, and 2.4.19 will be moreso, but not in the next week :)