On Mon, Dec 7, 2015 at 4:10 PM, Jacob Champion <champio...@gmail.com> wrote:
> On 12/07/2015 11:55 AM, Jacob Champion wrote: > >> > - moving things to post read sounds tempting, however I'm not sure if >> we want to upgrade on non-authed request or not, for example. I am not >> sure what else we do in post read, maybe someone else has an opinion >> about that. It certainly looks nicer in the OPTIONS * case. >> >> WebSocket upgrades rely on authn headers and cookies; there is no (good) >> way after a connection has been established to say "well, I upgraded you >> but now I'm closing the connection because you weren't authorized." The >> check needs to be done before sending 101 (and otherwise a 401/403/4xx >> needs to be sent instead of the upgrade). >> > > D'oh. My WebSocket rambling has nothing to do with anything you said -- I > only just realized you were both talking about mod_ssl's hook > implementations, not the general order of the hooks in the new Upgrade > architecture... > > Sorry for the noise. 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. ... 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?
