Do not CORS-safelist a Range header without a start

As per #1450 the intent was never to allow this. The algorithm before #1454 would yield undefined behavior for this input, but after it incorrectly ended up being allowed. This change makes it clearly disallowed.

Already tested in WPT cors/cors-safelisted-request-header.any.js.

Author: annevk

fetch.bs

@@ -923,8 +923,19 @@ fetch("https://victim.example/naïve-endpoint", {
     </div>
 
    <dt>`<code>range</code>`
-   <dd><p>If the result of <a>parse a single range header value</a> given <var>value</var> is
-   failure, then return false.
+   <dd>
+    <ol>
+     <li><p>Let <var>rangeValue</var> be the result of <a>parsing a single range header value</a>
+     given <var>value</var>.
+
+     <li><p>If <var>rangeValue</var> is failure, then return false.
+
+     <li>
+      <p>If <var>rangeValue</var>[0] is null, then return false.
+
+      <p class=note>As web browsers have historically not emitted ranges such as
+      `<code>bytes=-500</code>` this algorithm does not safelist them.
+    </ol>
 
    <dt>Otherwise
    <dd><p>Return false.