On Wed, Dec 9, 2015 at 9:22 PM, Jacob Champion <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 :)
