Code change:
infrastructure.  However, current gateways might need modifications to support TCP proxy services.  To be compatible, a gateway must: <del> support Extended CONNECT. </del> <ins> support Extended CONNECT (if acting as an HTTP/2 or HTTP/3 server). support HTTP/1.1 Upgrade to "connect-tcp" (if acting as an HTTP/1.1 server) only after forwarding the upgrade request to the origin and observing a success response. </ins> <del> convert HTTP/1.1 Upgrade requests into Extended CONNECT. </del> <ins> forward the "connect-tcp" protocol to the origin. </ins> <del> allow the Extended CONNECT method to pass through to the origin. </del> <ins> convert "connect-tcp" requests between all supported HTTP server and client versions. </ins> <del> forward Proxy-* request headers to the origin. </del> <ins> allow any "Proxy-Status" headers to traverse the gateway. </ins> 8.

Related discussion:
text: Related to and HTTP request proxies use "Proxy-Authenticate" in order to distinguish proxy authentication from destination authentication ("WWW-Authenticate") in the mixed bag of headers that is presented to the proxy. Classic HTTP CONNECT proxies don't have that problem, but they still use "Proxy-Authenticate", probably just for consistency. The MASQUE RFCs don't say anything about which authentication headers to use. "connect-tcp" and MASQUE should definitely follow the same rules, whatever they are. NAME noted that RFC 9110 says "the Proxy-Authenticate header field applies only to the next outbound client on the response chain". This implies that a general-purpose gateway is not expected to forward Proxy-Authenticate headers. However, there is actually no such thing as a general-purpose gateway for Extended CONNECT, so this seems somewhat moot. Personally, I think that our guidance should probably also line up with what we want to say for which is (in my view, despite some authors' protestations) a modernized HTTP request proxy.
An interesting related question is whether MASQUEish resources can be authenticated with other methods, like cookies and bearer tokens. If so, I think they are essentially "content-like" and should probably use WWW-Authenticate. If not, they are essentially distinct, and could conveniently be marked as such with "Proxy-Authenticate". Or perhaps they are both, depending on the context...
I somewhat think it's both — it's content and the proxy.
NAME Thank you for opening the issue. If we are to consider extended CONNECT gateways as proxies, then the question would be what the URI of the connect-tcp request means. RFC 9110 says that target URI specifies the origin. It is only because all the existing extended CONNECT family deals with origins that the TLS handshakes to those servers implementing the extended CONNECT family can be validated using certificates issued for that origin. To conclude, to me in seems that the use of WWW-Authenticate is mandated by the using URI as the target. PS. Note also that RFC 8441 specifically explains how proxies can be used between the client and the extended CONNECT target, see .
I don't think anything is really mandated. Within the current language of RFC 9110, I think we are free to choose either interpretation.