httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Champion <>
Subject Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls
Date Mon, 07 Dec 2015 23:21:28 GMT
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?

> ... 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.

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?


View raw message