CONNECT and prospective data

[MikeBishop]

The spec currently says this about data sent along with a CONNECT request:

Content within a CONNECT request message has no defined semantics; sending content in a CONNECT request might cause some existing implementations to reject the request.

Is there a demarcation between data "within" a request and data to be sent on the tunnel if it opens successfully? HTTP/2 and HTTP/3 are fairly specific that all DATA frames are data for the tunnel. Do we need to say anything about the client prospectively sending data before the proxy responds?

[royfielding]

We should decide what we want to allow. If HTTP/3 is going to send CONNECT data within HTTP/3 frame payloads after (or before) the recipient accepts the CONNECT, then we should specify it differently than how we specified CONNECT in 1.1. I am fine with that.

[reschke]

Hm. Does this imply we special-case 1.1, and require the HTTP/2/3 behaviour for new versions?

[royfielding]

Hm. Does this imply we special-case 1.1, and require the HTTP/2/3 behaviour for new versions?

I think it is already a special case for 1.1, so that's not a problem.

[reschke]

OK, let me rephrase this then :-).

Are we trying to make it consistent for all "new" versions?

[MikeBishop]

Given that CONNECT is specified on a version-by-version basis anyway, I think I'd rephrase it with something like this:

A CONNECT request message does not have a body. In some versions of HTTP, data following the request message is interpreted as data destined for the requested tunnel, if one is opened. In a version which does not specify the behavior of data received after the request, sending content with a CONNECT request might cause some existing implementations to reject the request.

CONNECT is one of those weird edges of the protocol where each version will have to respecify its behavior; we don't necessarily need to prescribe what it will be, just make allowances for versions to differ.