- From: nirmalk401 <notifications@github.com>
- Date: Tue, 24 Feb 2026 02:10:32 -0800
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/1910/3950545027@github.com>
nirmalk401 left a comment (whatwg/fetch#1910) After getting some input from Mozilla and reviewing past implementation attempts, I’m starting to think that solving this purely in Fetch may not be the cleanest path forward. A Fetch-only solution would require additional changes in HTML and CSS to plumb any opt-in signal through to declarative subresource fetches. While Fetch could theoretically make a standards-level shift to block interactive handling of all 401/407 challenges for subresources without a developer signal, prior attempts suggest that doing so risks breaking legitimate use cases. Even if we add `authPrompt` to `RequestInit`, that would only cover programmatic `fetch()` calls from JavaScript. It would not automatically apply to declarative fetches such as `<iframe>`, `<link rel="stylesheet">`, or CSS `@import`, which would require corresponding HTML/CSS spec updates. Given that, the CSP-based proposal (https://github.com/w3c/webappsec-csp/issues/801) may provide a cleaner solution. A document-level policy surface seems better aligned with the goal of giving embedding origins blanket control without expanding the HTML surface area. Curious to hear whether CSP might be the more appropriate primary vehicle for this. -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/1910#issuecomment-3950545027 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/fetch/issues/1910/3950545027@github.com>
Received on Tuesday, 24 February 2026 10:10:36 UTC