- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 19 Apr 2016 17:19:52 +1000
- To: Roy Fielding <fielding@gbiv.com>
- Cc: Craig Pratt <craig@ecaspia.com>, Göran Eriksson AP <goran.ap.eriksson@ericsson.com>, "STARK, BARBARA H" <bs7652@att.com>, Remy Lebeau <remy@lebeausoftware.org>, IETF HTTP BIS <ietf-http-wg@w3.org>
On 16 Apr 2016, at 6:42 AM, Roy T. Fielding <fielding@gbiv.com> wrote: > > 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). IIRC the issue is that the failure case for a cache -- especially in an intermediary -- is not so simple; if Content-Range parsing fails and something gets stored, the results are unpredictable, and *could* be a lot worse than an unsupported new range-unit (which would just get ignored). Historically, we've been shy about changing the semantics or syntax of widely-deployed protocol elements, for the excellent reason that we don't -- and can't -- know all of the implementations, or consequences. On the other hand, introducing a new range-unit is expensive; it won't be recognised and taken advantage of in things like proxy caches until they're updated, which we know can take a very long time. Furthermore, Rodger showed us a variety of bugs in existing client implementations that assume that the only range-unit that will ever exist is 'bytes'. It would be helpful if we had some data about implementation behaviours regarding these two things (open-ended Content-Range and new range-unit); even if we don't know all of the implementations, we might be able to rule out one (or both) of them based upon practicality. Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 19 April 2016 07:20:19 UTC