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.
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.
Again, I need to write code so I have some solid information for you all
instead of just speculation based on reading the source.
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...
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.
--Jacob
