On Tue, Dec 8, 2015 at 9:10 PM, Roy T. Fielding <field...@gbiv.com> wrote:
> > On Dec 8, 2015, at 2:07 AM, Stefan Eissing <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... > > 2. General handling of request bodies. Options: > > a setaside in core of up to nnn bytes before switch invocation > > b do nothing, let protocol switch handler care about it > > I think folks are confusing implementation with protocol. There is no need > for the protocol being read on a connection to be the same protocol that is > being written in response. In other words, the incoming connection remains > reading HTTP/1 bits until the message is finished, regardless of the > decision > to upgrade the response stream -- the other protocol engine doesn't care. > +1, between HTTP/1 and HTTP/2, or between HTTP/1 and websocket. (And we already worked out that websocket upgrade passes no request body anyways, right?) > 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. > 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. > > 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. > > 5. Will it be possible to migrate the current TLS upgrade handling to > this revised scheme? > > TLS upgrade is never done with a body (and is broken code anyway). Just > fix it. > Fixing (leveraging set-aside code that already exists in mod_ssl for TLS protocol renegotiation)... I see nothing in either RFC that suggests that upgrade to TLS with a request body is not permitted. You may be right about existing CUPS clients. Note that the upgrade token is "TLS" -- it does not have to be "TLS/1.0". > Funny, just working on this w.r.t. TLS vs TLS/1 vs TLS/1.x - we need to accept any of the above. We should reject TLS/1.3, and TLS/2 however, whenever mod_ssl/openssl is not configured handshake those protocols. I interpret the token version as the minimum acceptable handshake, e.g. any client that will handshake only TLS/1.1 or TLS/1.2 would send Upgrade: TLS or Upgrade: TLS/1 or Upgrade: TLS/1.1. The TLS handshake itself will present the best possible protocol level, while successfully negotiating this earlier protocol. We also must advertise TLS/1.1 (or TLS/1.2) if mod_ssl/openssl is not configured to accept TLS/1.0 (or TLS/1.1) handshakes. am I misinterpreting this?
