http-core
http-core copied to clipboard
Should ranges-specifier be friendlier for multiple Range headers?
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:
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.
"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.