Re: [whatwg/fetch] Add usage advice for Sec- (PR #1818)

@annevk commented on this pull request.



> +
+
+<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:].
+
+<p id=sec-purpose-no-sec class=example>The [:Sec-Purpose:] field tells a server that a
+<a for=/>request</a> is speculative. A server might choose to avoid triggering side-effects while
+processing such a request, such as suppressing the recording of page view metrics. Making this a
+<a>forbidden request-header</a> has no security-relevant purpose and the `<code>Sec-</code>` prefix
+is therefore unnecessary.

> Sending new headers has to be safe in HTTP.

This is not the case across the origin boundary. Please tell me which new headers browsers are sending across the origin boundary? Bonus points if their payloads can be attacker-controlled to some extent.

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

Message ID: <whatwg/fetch/pull/1818/review/2811618724@github.com>