- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 20 Apr 2016 23:11:30 +1000
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Craig Pratt <craig@ecaspia.com>, IETF HTTP BIS <ietf-http-wg@w3.org>
On 20 April 2016 at 17:50, Mark Nottingham <mnot@mnot.net> wrote: >> How about "b-live"? > > Better. If we choose to mint a new range-unit, it might be an opportunity to make other changes too, in which case it might be more generic; that would imply a different, more general name. But we're not there yet. Maybe I'm not 100% across the constraints that we're operating with here, but is there some way to achieve the basic goal here without committing to changes to the protocol? I ask because we have exactly one use of ranges in HTTP and that makes me highly skeptical that this particular extension point is actually extensible. As noted up-thread, many implementations make assumptions. That makes the chances that we can successfully make changes to the protocol quite slim, or at the very least they could be expensive. If we were to, say, accept that Range is how it is, and concentrated on using the protocol as it is to solve the problem, could that work, or is there some aspect to the problem that I'm missing? For example... If I were to request Range: 123456-* and that resulted in me receiving an entirely different response (maybe via redirect) that included the requested content with a "This-Is-Part-Of: <that other URL>; from=123456", would that work? Or, and I hesitate to suggest this, but it does avoid the extra request... Vary: Range.
Received on Wednesday, 20 April 2016 13:12:02 UTC