Oops, my earlier email got criss-crossed with this one.
On Apr 15, 2016, at 1:00 PM, Craig Pratt <craig@ecaspia.com<mailto:craig@ecaspia.com>> wrote:
[cp] Remy answered this: Content-Length is not expressly required (since that would prevent chunked and other transfer encodings). But the Content-Range header can only communicate a fixed response.
That is incorrect. See RFC7233, Sec 4.2:
For byte ranges, a sender SHOULD indicate the complete length of the
representation from which the range has been extracted, unless the
complete length is unknown or difficult to determine. An asterisk
character ("*") in place of the complete-length indicates that the
representation length was unknown when the header field was
generated.
The following example illustrates when the complete length of the
selected representation is known by the sender to be 1234 bytes:
Content-Range: bytes 42-1233/1234
and this second example illustrates when the complete length is
unknown:
Content-Range: bytes 42-1233/*
Oh, never mind, now I see that you are referring to the second number being fixed.
I think I would prefer that be solved by allowing last-byte-pos to be empty, just like
it is for the Range request. I think such a fix is just as likely to be interoperable as
introducing a special range type (same failure cases).
DT>> We would be ok with that approach too. Our initial thought was that it would be more invasive (less acceptable) so we opted for suggesting an alternate unit. That way we don’t break existing clients and any client that desires the “open-ended last-byte-pos” feature could support the new unit.
....Roy
Received on Friday, 15 April 2016 21:10:22 UTC