On 12/09/2015 09:17 AM, William A Rowe Jr wrote:
On Tue, Dec 8, 2015 at 9:10 PM, Roy T. Fielding <field...@gbiv.com
<mailto:field...@gbiv.com>> wrote:
> On Dec 8, 2015, at 2:07 AM, Stefan Eissing <stefan.eiss...@greenbytes.de
<mailto:stefan.eiss...@greenbytes.de>>
wrote:
>
> Open:
> 1. Protocols like Websocket need to take over the 101 sending themselves in the
"switch protocol" phase. (correct, Jacob?). Should we delegate the sending of the
101 to the protocol switch handler?
That seems unlikely.
Agreed, anywhere we like we can send the 101 with headers, all that the
websocket module needed to do was to set up output_headers or perhaps we
add intermediate_output_headers in the request structure. Easily fixed
so this code is still common...
+1.
This should be easily handled by adding a filter that translates the
HTTP/1
incoming body (if any) to a single channel of the new protocol.
Just fake it.
There is no need to wait or set aside the bytes, unless that is
desired for
other reasons (e.g., denial of denial of service attacks).
However, we must read the request body complete before the input handler
is toggled to the h2c state, or before we switch to any bidirectional
protocol, e.g. TLS or otherwise.
For my own clarification: this is a protocol-specific limitation, right?
As in, you can't begin a TLS handshake without first draining the
incoming request body off the connection.
> 3. When to do the upgrade dance:
> a post_read_request: upgrade precedes authentication
> b handler: upgrade only honored on authenticated and otherwise ok
requests
> c both: introduce separate hooks? have an additional parameter? more
complexity
(a). We do want to upgrade non-ok responses. If the "new" protocol
wants to
send a canned HTTP/1.1 error, it can do so without our help.
+1 in the case of h2c, TLS. I understand that websocket upgrades are
going to be conditional on authentication. As long as we give websocket
the chance to upgrade in the fixups or similar phase, after auth, then
websocket can ignore the Upgrade: websocket offer after inspecting authnz.
Sounds reasonable. Unfortunate in the sense that it's possible for a
module implementing the Upgrade API to screw up and accidentally ignore
authnz, but since most protocols we're talking about can safely upgrade
first and respond with 401/3 on the new protocol, I don't see much of an
alternative.
> 4. status code of protocol switch handler: if we move the task of 101 sending, the
switch handler might not do it and keep the connection on the "old" protocol. Then
a connection close is not necessary. So, we would do the close only when the switch handler
returns APR_EOF.
Eh?
I'm wondering the same, the new protocol loop can do all of the
connection handling, no need for the protocol switch to do anything but
continue, if the connection is ended in the protocol handler, it's gone.
Why leave it up to the protocol handler (to potentially get wrong)? Are
there any cases where, after a successful upgrade, we would not want to
close the connection upon returning from the protocol handler?
--Jacob
