section #connections is vague wrt connection is HTTP or HTTPS or HTTP/2 or QUIC

[equalsJeffH]

The obtain a connection algorithm in section #connections presently says this:

Set connection to the result of establishing an HTTP connection to origin. [HTTP] [HTTP-SEMANTICS] [HTTP-COND] [HTTP-CACHING] [HTTP-AUTH] [TLS]

If credentials is false, then do not send a TLS client certificate.

However, one is not going to "send a TLS client certificate" if one is not running over TLS, and there is no context in this alg whether or not a HTTP or HTTPS or HTTP/2 or QUIC or whatever connection is established.

Given the associated Note says in part: "This is intentionally a little vague as the finer points are still evolving." this is likely understood, tho I did not find an already-open issue regarding this, thus am submitting this one.

Offhand, it seems one way to nominally address this is to:

• declare a connectionType enum with values of "HTTP, HTTPS, HTTP/2, QUIC" (for now),
• pass a connectionType param to the obtain a connection algorithm,
• add connectionType as part of the per-connection state maintained by the connection pool
• add logic to obtain a connection alg to open conn of specific type per connectionType.

[sleevi]

@equalsJeffH I'm working on Chrome's implementation of this, but I'm unclear about what the implications of this are?

That is, at least as implemented in Chrome (and others, from what I've seen), whether or not to send a certificate is somewhat of a state independent of the underlying transport, and the underlying transport doesn't support certificates, it simply doesn't send them.

Is the concern about it being specific to TLS? Would it also work to say: "If credentials is false, do not send a certificate" (e.g. omitting TLS to support QUIC or HTTP/2 certificate frames, and omitting client to avoid any ambiguity about what type of certificate)

[sleevi]

Separately, I'm not aware of implementations that guarantee opening specific connection types, nor would I think Chrome be supportive of such language or (web developer) flexibility :)

[equalsJeffH]

thx for explanation @sleevi
so i happened to return to reviewing the obtain a connection section and was again sort of confused and having questions and then I recalled having submitted this issue. Upon re-reading this, I suppose that at least at this point, I'd say yes, omit "TLS" from "If credentials is false, do not send a TLS certificate", and consider expanding the existing Note to contain appropriate portions of #641 (comment) and #641 (comment) (above) such that there's less mystery regarding the admitted vagueness.

[equalsJeffH]

also, perhaps this:

Set connection to the result of establishing an HTTP connection to origin . [HTTP] [HTTP-SEMANTICS] [HTTP-COND] [HTTP-CACHING] [HTTP-AUTH] [TLS]

..could explain more, e.g.:

Set connection to the result of establishing an HTTP connection to origin . Depending on various factors, the connection may actually be HTTP (over insecure transport), HTTP over TLS ("HTTPS"), HTTP/2 ("h2") over TLS, QUIC, or perhaps HTTP over some other secure transport. [followed by appropriate series of spec references].

[sleevi]

Could you help me understand why it matters or how it would be observable or relevant to consuming specs?