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:[email protected]]
Sent: donderdag 10 december 2015 07:40
To: httpd <[email protected]>
Subject: Re: Upgrade Summary
On Wed, Dec 9, 2015 at 9:22 PM, Jacob Champion <[email protected]
<mailto:[email protected]> > 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 :)
