httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <>
Subject RE: Upgrade Summary
Date Thu, 10 Dec 2015 10:45:35 GMT
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.





From: William A Rowe Jr [] 
Sent: donderdag 10 december 2015 07:40
To: httpd <>
Subject: Re: Upgrade Summary


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


View raw message