"Connection"

[mnot]

Semantics uses "Connection" to mean both "the underlying transport-layer substrate" and "the logical channel that a particular request/response exchange uses" (roughly).

They are the same in H1, but not in H2 and later. Should we consider using a separate term for the latter (e.g., "channel")?

[LPardue]

A different term would help when discussing proxying in H2 or HQ, where a channel is carried over a stream.

[royfielding]

It is a defined term except where we are specifically describing TCP. We can fix the latter part easily.

Using a different term would be a huge change, not only to our own specs but to all the ones downstream. Think of how many specs normatively refer to HTTP.

If we do choose a different term, it can't be one already in use for framing. That means no channels, streams, frames, or anything else that might be in h3+. And it has to mean the same thing as the Connection defined term, since otherwise we have to add extra phrasing where it currently occurs.

[mnot]

How many downstream specs refer to a HTTP connection? Hopefully none, since it's a stateless protocol.

[mnot]

Also, I suspect that "stream" would work very well, since it's semantics in h2 and QUIC is what we're looking for.

[royfielding]

stream does not work -- that is a unidirectional term

[mnot]

It's not unidirectional in H2, and only sometimes in QUIC (currently).

Looking at Semantics again, it seems like the most minimal change we could make would be to:

• Add text at the start of 2.1 client/server messaging explicitly distinguishing between "connection" and "transport connection", with "TCP connection" a subclass of the latter.

• In 1. Introduction, "This document obsoletes the portions of RFC 7230 that are independent of the HTTP/1.1 messaging syntax and transport connection management"

• The sentence in 2.1 starting with "A connection might be used for multiple..." is confusing; I'm not sure what to do here yet.

• in 2.5.1 http URI Scheme, change 5th para 1st sentence to "Note that the presence of a URI with a given authority component does not imply that there is always an HTTP server listening for TCP connections on that host and port."

• Same section, second to last sentence - s/underlying connection protocol/underlying transport protocol/ and s/end-to-end secured connection/end-to-end secured transport/

• In 5.2 Routing Inbound, "HTTP requirements regarding TCP connection management in HTTP/1.1 are defined in..."

• In 8.5.1 Challenge and Response, s/underlying connection/underlying transport connection/

• In 8.5.5.2, same change (and update plain "connection" in same sentence likewise)

• In 9.2.2 101 Switching Protocols, we probably need to have a discussion. H2 disallows it, so this might need to move to H1-messaging.

• In 9.3.3 202 Accepted, s/user agent's connection/user agent's transport connection/

• 205 Reset Content paragraph 3 is H1-specific, so will need to change anyway.

• 408 Request Timeout is H1-specific, so will need to change anyway.

• 413 Payload Too Large last sentence of first paragraph, "close" feels specific to transport connections; perhaps "terminate" instead? Although, H2 streams are closed too...

• 9.6.4 503 Service Unavailable "Some servers might simply refuse the transport connection."

• 12.14.1 Confidentiality of Credentials - qualify bare "connection" with "transport", two places

H1-messaging will need to have similar changes; if the above is an acceptable approach overall, I'll do a PR for both. Thoughts?

[martinthomson]

408 seems like it is generally applicable. I mean, h2/h3 might choose to reset a stream, but I imagine that 408 is still a valid choice for handling a laggardly client.

The Section 2.1 text just needs to be recast so that it is version specific: All versions of HTTP use a connection for multiple request/response exchanges, but the manner in which they do so is version-specific. This includes how connections are established and managed, how requests and responses are correlated, all the details of encoding, and other aspects like cancellation and reliability.

[mnot]

408 currently says:

A server should send the "close" connection option (Section 9.1 of [Messaging]) in the response, since 408 implies that the server has decided to close the connection rather than continue waiting. If the client has an outstanding request in transit, the client may repeat that request on a new connection.

In H2 you can't send the "close connection option; so, this text will need to change.

WRT 2.1 - please go through and look at all of the uses of "connection" in the document; many of them refer to the specific HTTP request/response exchange path, not the underlying transport.

[wtarreau]

For having dealt with this H1 vs H2 stuff very recently, I figured that we absolutely ought to remove any wording about the connection header in the version-agnostic parts. What is being said here for 408 is valid for every other responses in H1 in fact. We should instead stipulate in the H1 transport parts that whenever the response is expected to be the latest one on the connection, the server ought to add a "connection: close" header field so that the client immediately knows that possibly other outstanding requests were not processed.

[mnot]

Taking another look at this, I think we can do an even more minimal approach (helped by the other work to remove h1-specific terminology and requirements, this isn't nearly as confusing, with a few small modifications).

There is some remaining language in CONNECT that's not appropriate, but that should be covered by #183 and #340.