Re: Resend: HTTP/2 extended CONNECT and HTTP Digest authentication underspecified interaction

Agreed, this is a real issue that impacts all uses of extended CONNECT. I
think it might warrant a new document that updates 7616, 8441, and 9220.
That said, if we have deployed code in clients and servers that does
different things, we're already in a not-great place. I'm not sure what the
best path forward is.
David

On Mon, Sep 9, 2024 at 11:06 AM Ben Schwartz <bemasc@meta.com> wrote:

> This is a very interesting situation.  Naively, it would seem that
> "CONNECT" is the method.  However, if the backend is speaking HTTP/1.1
> through a WebSocket+HTTP/2 gateway, then the method will be rewritten, and
> the client and origin will disagree about the method.  Uh-oh...
>
> I note that this question applies equally to the MASQUE protocols as well.
>
> --Ben
> ------------------------------
> *From:* Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>
> *Sent:* Saturday, September 7, 2024 3:34 PM
> *To:* ietf-http-wg@w3.org <ietf-http-wg@w3.org>
> *Subject:* Resend: 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://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8441*section-5__;Iw!!Bt8RZUm9aw!_XAO6g6jKg8a6LjJF1pes96XdZUyXBqFmfVagX07zsljijOtnuSxcMo9Z_OA4ydTnQkb-XKBpeb9n9It8SP7tqQN0g$
> notes that
>
> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc6455__;!!Bt8RZUm9aw!_XAO6g6jKg8a6LjJF1pes96XdZUyXBqFmfVagX07zsljijOtnuSxcMo9Z_OA4ydTnQkb-XKBpeb9n9It8SNrZLfEhA$
> 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://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8441__;!!Bt8RZUm9aw!_XAO6g6jKg8a6LjJF1pes96XdZUyXBqFmfVagX07zsljijOtnuSxcMo9Z_OA4ydTnQkb-XKBpeb9n9It8SO0ieiuJg$
>
> [2] HTTP Digest Access Authentication
>
> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc7616__;!!Bt8RZUm9aw!_XAO6g6jKg8a6LjJF1pes96XdZUyXBqFmfVagX07zsljijOtnuSxcMo9Z_OA4ydTnQkb-XKBpeb9n9It8SN3O7gn9g$
>
> [3]
> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc7616*section-3.4.3__;Iw!!Bt8RZUm9aw!_XAO6g6jKg8a6LjJF1pes96XdZUyXBqFmfVagX07zsljijOtnuSxcMo9Z_OA4ydTnQkb-XKBpeb9n9It8SN0bz9bqA$
>
> [4]
> https://urldefense.com/v3/__https://redmine.lighttpd.net/boards/2/topics/11676__;!!Bt8RZUm9aw!_XAO6g6jKg8a6LjJF1pes96XdZUyXBqFmfVagX07zsljijOtnuSxcMo9Z_OA4ydTnQkb-XKBpeb9n9It8SP1M5JQhw$
>
>