Re: issue 85 - range unit extensions

----- Original Message ----- 
From: "Jamie Lokier" <jamie@shareable.org>
To: "Kris Zyp" <kris@sitepen.com>
Cc: "Henrik Nordstrom" <henrik@henriknordstrom.net>; "ietf-http-wg" 
<ietf-http-wg@w3.org>
Sent: Tuesday, September 02, 2008 5:22 PM
Subject: Re: issue 85 - range unit extensions


> Kris Zyp wrote:
>>
>> >tis 2008-09-02 klockan 08:37 -0600 skrev Kris Zyp:
>> >
>> >>I didn't know there was such rules for alternate range units.
>> >
>> >There isn't any struct rules for range units, but this property is
>> >highly desireable for different implementations to interoperate properly
>> >when it comes to merging and splitting.
>>
>> After thinking about this, I actually have no problem with this rule 
>> being
>> enforced, I think that is a good suggestion. I had been thinking it would
>> be more desirable that the individual "ranged" response representations 
>> all
>> be valid complete JSON messages themselves, but I don't think that is
>> necessary. I am perfectly fine with have ranges all being concatenable
>> without any JSON parsing.
>>
>> GET /jsonResource
>> Range: items=0-1
>>
>> response:
>> ["a","b",
>>
>> GET /jsonResource
>> Range: items=2-
>>
>> response:
>> "c","d"]
>>
>> GET /jsonResource
>>
>> response:
>> ["a","b","c","d"]
>>
>> A puts little extra overhead on the client doing JSON parsing to properly
>> pre/postpend the string to parse it, but this is a negligible cost...
>
> What about
>
> Range: items=2-4
> Range: items=2-5
>

In my example there were four items in the array, so your Range requests 
(2-4 and 2-5) should result in 416 Requested Range Not Satisfiable.

> Is the JSON parser expected to look at the text it receives to decide
> whether to append "]"?

The JSON parser could look at the text or the Content-Range header (to see 
if it received the last item). I am not sure which would be more reliable.

> If so, why bother sending the "[" and "]" at all?

The cumulative concatenated representation must be valid JSON.

Kris

Received on Tuesday, 2 September 2008 23:45:58 UTC