- From: Martin Thomson <notifications@github.com>
- Date: Fri, 11 Apr 2025 08:40:04 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/pull/1818/review/2760765743@github.com>
@martinthomson commented on this pull request. > +there are cases where information might be spoofed by a malicious client. + +<p id=why-sec-fetch-dest-is-sec class=example>The [:Sec-Fetch-Dest:] <a>header</a> might be used in +<a for=/>requests</a> both with or without <a for=/>credentials</a>. The decisions that a server makes using +[:Sec-Fetch-Dest:] can be security-relevant for an honest user agent, even for <a for=/>requests</a> +without credentials. + + +<h4 id=sec-not-ok>Reasons not to use a `<code>Sec-</code>` prefix</h4> + +<p>That a <a>header</a> value might be needed to answer a <a>CORS-preflight request</a> is +<em>not</em> a sufficient reason to use a `<code>Sec-</code>` prefix; all <a>CORS-preflight +requests</a> include [:Access-Control-Request-Method:], which is [=forbidden +request-headers|forbidden=]. Any <a for=/>headers</a> that a fetch caller sets will not be set on a +<a>CORS-preflight request</a> made by an honest user agent; instead, these are listed in +[:Access-Control-Request-Headers:]. I disagree. It's quite a compelling example in that it is forbidden for a very good reason. (I don't know why you quoted the unrelated text about ACRH, is there a point you wanted to make there? -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/pull/1818#discussion_r2039805424 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/fetch/pull/1818/review/2760765743@github.com>
Received on Friday, 11 April 2025 15:40:08 UTC