Open annevk opened 2 years ago
"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?
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.
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.
While reviewing https://github.com/web-platform-tests/wpt/pull/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:and instead you'd have to write
or
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.