- From: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>
- Date: Sat, 7 Sep 2024 15:34:56 -0400
- To: ietf-http-wg@w3.org
There appears to be an underspecified interaction with HTTP/2 extended
CONNECT and HTTP Digest authentication when clients evaluate wss://.
With the HTTP/2 extended CONNECT method [1], the :method is CONNECT.
With wss:// using HTTP/2 extended CONNECT, the :method is CONNECT.
If there is HTTP Digest authentication [2], then the HTTP request
method is part of A2 if the qop parameter's value is "auth" or is
unspecified. [3]
An inconsistency has been reported to me: [4]
With wss://, Firefox and Chromium both produce a digest using "GET" as
the HTTP method, but if using an HTTP/2 connection, use HTTP/2 extended
CONNECT for wss://. For HTTP/2 extended CONNECT, lighttpd produces a
digest using "CONNECT" as the HTTP method, and HTTP Digest
authentication fails due to the mismatch of the hashes.
https://www.rfc-editor.org/rfc/rfc8441#section-5 notes that
https://www.rfc-editor.org/rfc/rfc6455 uses a GET-based request in
WebSockets opening handshake, but I did not find additional relevant
references to GET.
Which is proper behavior with wss:// using HTTP/2 extended CONNECT and
HTTP Digest authentication? Should "CONNECT" be used as the HTTP method
for A2, or should "GET" be used as the HTTP method for A2, even though
:method is CONNECT? Should this be an Errata to RFC8441 to better
specify the correct behavior with HTTP2 (and HTTP/3)?
Scripts to reproduce the issue can be found in [4].
Thank you for your input.
Cheers, Glenn
[1] Bootstrapping WebSockets with HTTP/2
https://www.rfc-editor.org/rfc/rfc8441
[2] HTTP Digest Access Authentication
https://www.rfc-editor.org/rfc/rfc7616
[3] https://www.rfc-editor.org/rfc/rfc7616#section-3.4.3
[4] https://redmine.lighttpd.net/boards/2/topics/11676
Received on Saturday, 7 September 2024 19:35:10 UTC