httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls
Date Mon, 07 Dec 2015 23:49:55 GMT
On Mon, Dec 7, 2015 at 5:21 PM, Jacob Champion <> wrote:

> On 12/07/2015 02:40 PM, William A Rowe Jr wrote:
>> Not "noise" at all... I'm imagining a mod_echo protocol example that
>> looks much like your use case...
>> 1st call to core_upgrade_request in post_read_req hook, after setenvif
>> and mod_headers processing... tls is ready, echo (or websocket) would
>> not be ready.  Those ready indicate via ap_select_protocol hook response.
> Just to confirm, the purpose of splitting this up into two separate calls
> to the same function is solely to deal with "OPTIONS *", which doesn't
> follow the same logical path in httpd? Or is there another reason?

No, it is because the TLS handshake from the Upgrade: TLS  handling
is used in the auth path, everything from SSLRequireSSL to using the
CN of a client certificate for authentication.

TLS Upgrade must occur somewhere early in the post_read_request
phase of operation.  For that matter, so should h2c, I'd imagine, but
those phases may already be invoked a second time in mod_http2,
someone else could verify or disclaim that.

... normal pre-handler request preparation and auth ...
>> 2nd call to core_upgrade_request in ap_invoke_handler hook, after all
>> of these other preparations but excluding filter configuration (filters
>> may
>> differ for the new protocol), tls was handled earlier, echo (or websocket)
>> are now ready, based on auth results.  Those ready again indicate
>> via ap_select_protocol hook response.
>> WDYT?
> I have a suspicion that this isn't quite enough, at least not with the
> code that's currently there. I really need to write code to confirm, but:
> if WebSocket is enabled for the request-target path, but the upgrade
> request is malformed, I still want my module to propose a WebSocket upgrade
> to core, so that I have the ability to fail said upgrade with a 4xx _if_
> we're chosen as the eventual protocol. (If a different protocol is chosen,
> the client lucks out.)
> Put another way, I'm going to propose WebSocket for the paths that the
> server admin wants, whether the incoming request is valid/authorized or
> not, and I still need some way to interrupt the upgrade if we're chosen and
> the client hasn't sent a proper request. Does that makes sense?

So how would a second invocation during the ap_invoke_handler cause
an interruption in this?

Upgrade: TLS would occur in the early processing, Upgrade: WebSocket
would occur in the later processing phase, but still prior to invoking a
for the HTTP/1.1 request.  Remember that there is no 'error' for a malformed
upgrade request, only a failure to proceed with 101-switching protocols.

Right now the core Protocol API will only send an Upgrade: offer on the
first request in a chain of keepalive requests.  If the user agent asks for
OPTIONS * and the WebSocket module declines to offer itself, and the
user agent continues with a GET /webapp/... request that the WebSocket
module is willing to upgrade, today the core Protocol API will not advertise
that to the user agent on this kept-alive request for you.

Of course there is a fail-case, and that would be Upgrade Required, but
the protocol module needs to set this sometime before handler invocation.
Right now you can't do that within core_upgrade_request hooks, because
without an Upgrade: request from the client, the core_upgrade_request
implementation calls none of the protocol hooks on a kept-alive 2nd or
later request, right now.

Stupid question, is there an Upgrade: of protocols within HTTP/2?  An
obvious case would be the websocket connection embedded within the
h2c connection, but I expect that is not allowed.  TLS upgrade would be
nonsense on an h2c connection.  But is there a provision for it in spec?

View raw message