On Tue, Dec 8, 2015 at 4:17 PM, Yann Ylavic <[email protected]> wrote:
> On Tue, Dec 8, 2015 at 11:00 PM, William A Rowe Jr <[email protected]> > wrote: > > > > Define complex, robust. Request (upgrade: somespec) -> 100 continue -> > > request body <- [ http/1.1 response | 101 - switching protocols <- new > > protocol response ]. > > As I read the RFC, the simple(st) case is: > Request (upgrade: somespec) -> request body <- 101 (upgrade: somespec) > <- new protocol response or read > Whereas the 100-continue case is: > Request (upgrade: somespec, expect: 100-continue) [ <- 100-continue -> > request body ] <- 101 (upgrade: somespec) <- new protocol response or > read > Right, and I didn't color the complexity of using C-L vs. T-E encoding for the request body, either. Both may reply in http/1.1 or with a 101-switching followed by something recognizable (e.g. tls following handshake and filter insertion) or inscrutable (e.g. websocket, h2c) to the http/1.1 protocol stack. > Why any HTTP/1 response? If the Upgrade is accepted, ISTM that the > response must be Upgraded, no? > The server is always free to accept or ignore the Upgrade: request... and once the 101-switching protocols has been sent, the connection must be in the offered protocol. 6.7 <https://tools.ietf.org/html/rfc7230#section-6.7>. Upgrade The "Upgrade" header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other protocol on the same connection. A client MAY send a list of protocols in the Upgrade header field of a request to invite the server to switch to one or more of those protocols, in order of descending preference, before sending the final response. A server MAY ignore a received Upgrade header field if it wishes to continue using the current protocol on that connection. Upgrade cannot be used to insist on a protocol change.
