On Mon, Dec 7, 2015 at 7:25 PM, Jacob Champion <champio...@gmail.com> wrote:
> On 12/07/2015 03:49 PM, William A Rowe Jr wrote: > >> 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. >> > > Oh, I see. Thanks for the clarification. > > 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? >> > > I don't think it would; that comment was unrelated to the "two calls" > clarification. I'm just trying to work through whether or not the current > architecture is sufficient for my use case. I think it may be... > > Upgrade: TLS would occur in the early processing, Upgrade: WebSocket >> would occur in the later processing phase, but still prior to invoking a >> handler >> 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. >> > > From the HTTP/1.1 point of view, yes. I could choose to simply ignore bad > upgrades, eventually fall back to the file handler, and be perfectly > HTTP-compliant. > > From the WebSocket point of view, though, server implementations have to > reject improper upgrades with a 4xx. Letting a bad upgrade fall through to > some other handler (which could possibly return 200 and some document) is > non-compliant behavior. It would be nice (TM) if I had a hook to "accept > the upgrade" (from httpd's point of view, not the client's), but perform my > checks and send back an error code before the 101 proceeded. The only other > option I see is to inject myself as a handler in an error case and hope I'm > not preempted by some other module. > You can ap_die anywhere during the pre-handler phases, between or before the second protocol switch offer. What you are describing seems like something well handled within the auth stack or in final fixups, no? That would include any upgrade-required status (as tls is going to do for SSLRequireSSL when SSL optional is configured). > Again, I need to write code so I have some solid information for you all > instead of just speculation based on reading the source. :) I would have dove deeper already but this conversation had to happen first, thanks for all the details of this specific use case. > 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. >> > > Ah. That is unfortunate... > ... but fixable. Perhaps the advertising hook determines if it will 're-advertise', or not? 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? >> > > No. Upgrade semantics are explicitly removed from HTTP/2 (section 8.1.1). > I assume the rationale is that other protocols can be negotiated directly > via either ALPN or HTTP/1.1 Upgrades, just like HTTP/2 is. > Thanks for clarifying.
