Interest in a UDP equivalent to the CONNECT method

Hi,

I'm wondering if there is interest from the WG in the following space before investing any more technical effort.

It recently struck me that there might be a use in iterating upon the CONNECT method, in order to support a world of UDP servers that support HTTP/QUIC. That spec neatly summarises the current state of play:


   In HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a
   tunnel to a remote host.  In HTTP/2, the CONNECT method is used to
   establish a tunnel over a single HTTP/2 stream to a remote host for
   similar purposes.

   A CONNECT request in HTTP/QUIC functions in the same manner as in
   HTTP/2.  The request MUST be formatted as described in [RFC7540],
   Section 8.3<https://tools.ietf.org/html/rfc7540#section-8.3>.  A CONNECT request that does not conform to these
   restrictions is malformed.  The request stream MUST NOT be half-
   closed at the end of the request.

   A proxy that supports CONNECT establishes a TCP connection
   ([RFC0793<https://tools.ietf.org/html/rfc0793>]) to the server identified in the ":authority" pseudo-
   header field.  Once this connection is successfully established, the
   proxy sends a HEADERS frame containing a 2xx series status code to
   the client, as defined in [RFC7231], Section 4.3.6<https://tools.ietf.org/html/rfc7231#section-4.3.6>.

The sad part here is that an HTTP/QUIC client that uses an HTTP/QUIC proxy in this mode needs to support TCP for secure connection to the remote host. This presents some resistance to moving away from TCP in the future.

I wondered if something better could exist, and Ben Schwartz and I batted some ideas around. The strongest one was the idea of a new method (e.g. UDPBIND) that would allow a client to indicate to the proxy that it wished to communicate with the remote host using UDP. Depending on the protocol being used for client-to-proxy communication some options present themselves (NB: the data exchanged is the serialization of TLS handshake and protected packet format):


  *   HTTP/QUIC
     *   DATA frames sent by client (UDP) are transmitted by the proxy to the remote host UDP port (UDP).
     *   data received by the proxy (UDP) is packaged into DATA frames, which are then transmitted to the client (UDP).
  *   HTTP/2
     *   DATA frames sent by client (TCP) are transmitted by the proxy to the remote host UDP port (UDP).
     *   data received by the proxy (UDP) is packaged into DATA frames, which are then transmitted to the client (TCP).
  *   HTTP/1.1 ?
     *   data sent by the client (TCP) is transmitted by the proxy to the remote host UDP port (UDP).
     *   data received by the proxy (UDP) is transmitted to the client (TCP).

The conversion between TCP and UDP should be treated carefully, payloads may be segmented unexpectedly.

The handling of UDP "closure" is a problem area that needs more thought.

Kind regards
Lucas