Range header 'helper' produces incorrect header value

[whymarrh]

Snapshot: d20e8c9

The spec currently outlines the process for adding a Range header to a request:

To add a range header to a request request, with an integer first, and an optional integer last, run these steps:​

1. Let rangeValue be `bytes `.
2. Serialize and isomorphic encode first, and append the result to rangeValue.
3. Append 0x2D (-) to rangeValue.
4. If last is given, then serialize and isomorphic encode it, and append the result to rangeValue.
5. Append `Range`/rangeValue to request’s header list.

As an example, if first and last had values of 3 and 5, I think this would result in a Range header value of bytes 3-5 when it should be bytes=3-5, with 0x3D (=) as the separator.

Per RFC 7233 §2.1:^[1]

The "bytes" range unit is defined for expressing subranges of the data's octet sequence.

bytes-unit       = "bytes"

[…]

byte-ranges-specifier = bytes-unit "=" byte-range-set
byte-range-set  = 1#( byte-range-spec / suffix-byte-range-spec )

Examples of byte-ranges-specifier values:

• The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-499
• The second 500 bytes (byte offsets 500-999, inclusive): bytes=500-999

It should be a simple enough fix, unless I'm missing something:

- <li><p>Let <var>rangeValue</var> be `<code>bytes </code>`.
+ <li><p>Let <var>rangeValue</var> be `<code>bytes=</code>`.

I'm willing to open a PR for this, if that would be useful.

[annevk]

If you can also sign https://participate.whatwg.org/agreement, that would be great!

cc @jakearchibald

[annevk]

This was fixed as part of #1312 in 6f37b51, but we forgot to note it in the final commit message.