httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: On the Upgrade request body limit
Date Tue, 08 Dec 2015 22:43:25 GMT
On Tue, Dec 8, 2015 at 4:17 PM, Yann Ylavic <> wrote:

> On Tue, Dec 8, 2015 at 11:00 PM, William A Rowe Jr <>
> 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
followed by something recognizable (e.g. tls following handshake and filter
insertion) or inscrutable (e.g. websocket, h2c) to the http/1.1 protocol

> 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 <>.  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

View raw message