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