> On 16 Oct 2020, at 10:44 am, Mirja Kuehlewind
> <[email protected]> wrote:
>
> HI Lucas,
>
> RFC7231 defines CONNECT originally like this:
>
> “The CONNECT method requests that the recipient establish a tunnel to
> the destination origin server identified by the request-target and,
> if successful, thereafter restrict its behavior to blind forwarding
> of packets, in both directions, until the tunnel is closed.”
>
> So I would interpret that the connection is not really a HTTP connection
> anymore after it has concluded the CONNECT. Again in HTTP/2 this did work
> because of multiplexing but in HTTP/3 is would work again and effectively
> maybe be the more flexible solution.
In the current revision of the spec
<https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#CONNECT>,
that's followed by:
> Because CONNECT changes the request/response nature of an HTTP connection,
> specific HTTP versions might have different ways of mapping its semantics
> into the protocol's wire format.
Note that it *doesn't* say (in either version) that the *connection* is
converted into a tunnel; rather, only that one is established. As we now more
explicitly point out, the mapping to transport connections depends on the
version of the protocol in use; in h3, it isn't the whole connection.
Additional background here: <https://github.com/httpwg/http-core/issues/144>
Cheers,
--
Mark Nottingham https://www.mnot.net/
