Should ranges-specifier be friendlier for multiple Range headers?

[annevk]

While reviewing web-platform-tests/wpt#34384 I noticed that the Range request header has a rather unusual production, in that it allows for commas, but what can come before and after the comma isn't equal. E.g., it seems that this would be invalid:

Range: bytes=1-2
Range: bytes=-2

and instead you'd have to write

Range: bytes=1-2
Range: -2

or

Range: bytes=1-2,-2

I didn't encountered this usage of commas before so I thought this might be worth pointing out in a note or some such. And perhaps it's even worth changing such that bytes= is allowed to be repeated.

[reschke]

"Range" is not a list-based field, so the first two of your examples are invalid.

Is there a specific reason why you want to introduce a new syntactical variant?

[annevk]

It's my understanding that a naïvely-combining intermediary can rewrite the first two examples. At which point the distinction is lost.

I thought that because of that there was some implicit agreement that a header value parser would always operate on the combined header value (with the sole exception of Set-Cookie).

Other than that I think

Range: bytes=1-2
Range: -2

ought to be equivalent to

Range: bytes=1-2,-2

I don't have a strong opinion here.

[reschke]

It's my understanding that a naïvely-combining intermediary can rewrite the first two examples. At which point the distinction is lost.

yes.

I thought that because of that there was some implicit agreement that a header value parser would always operate on the combined header value (with the sole exception of Set-Cookie).

yes.

Other than that I think

Range: bytes=1-2
Range: -2

ought to be equivalent to

Range: bytes=1-2,-2

I don't have a strong opinion here.

Hm, no. the first one is invalid, the second one is valid. Recipients are not required to detect the brokenness, but if they can they should.