HTTP/2 extended CONNECT and HTTP Digest authentication underspecified interaction

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, 17 August 2024 09:07:13 UTC