- 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