Re: [whatwg/fetch] Explain the use-URL-credentials flag (PR #1498)

@domenic commented on this pull request.



> @@ -1781,6 +1781,12 @@ which is "<code>omit</code>", "<code>same-origin</code>", or
 <dfn export for=request id=concept-request-use-url-credentials-flag>use-URL-credentials flag</dfn>.
 Unless stated otherwise, it is unset.
 
+<p class=note>This flag controls whether the <a for=/>request</a>'s <a for=request>URL</a>'s
+<a for=url>username</a> and <a for=url>password</a> will be used to look up an
+<a>authentication entry</a> or not. Modern specifications avoid setting it, since putting
+credentials in <a for=/>URLs</a> is discouraged, but some older features set it for compatibility
+reasons.

> Presumably that would then result in a 401 after which the URL credentials would be used, no?

Eh, seems like it depends on whether the 401 results in a re-request with the prompted credentials in the URL, or in the side table. Which I'm not sure about.

> I think what's more surprising is that we end up using URL credentials when the UUC flag is not set. That seems like a bug of sorts.

My interpretation (and what I'm revising this PR to do) is that the current spec uses the flag to preference URL credentials over side table credentials, if both are present. If only one of the two is present, then it still gets used, regardless of the flag.

But, that's not how Chromium seems to behave per #1496 at least, so yeah, maybe a bug. I'll comment over there. We could add an XXX pointing to that issue if you think it's a good idea?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1498#discussion_r987514130
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1498/review/1130856760@github.com>

Received on Wednesday, 5 October 2022 03:49:19 UTC