Re: 303 for paging; was Re: 2NN Contents Of Related (303 Shortcut)

On 09/08/2014 09:47 AM, Julian Reschke wrote:
> On 2014-09-08 15:20, Sandro Hawke wrote:
>> ...
>> Can you point me to the part of a spec which says clients should treat
>> all unknown 2xx codes as if they were 200?     I don't think that's how
>> unknown 2xx codes are supposed to be handled.
>> ...
>
> <http://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7231.html#rfc.section.6.p.2> 
>
>

Thank you.    That would seem to kill 2NN Contents-of-Related as 
proposed.   I'm surprised no one has noticed/mentioned it before.

Am I reading it correct to imply that a client MAY treat any 2xx code 
(modulo caching) as a 200 simply by saying it "doesn't implement" the 
given 2xx?

I suppose it would work as 5NN, then.    Essentially, "I can't provide 
the content, since it's too large, but I am going to give you the first 
page of it."


> > ...
>> It's possible we did this design before realizing Range could be used
>> with units other than bytes.   Do you know of any deployments with
>> non-byte units?
>>
>> Is there a way to make Range work with changing resource state? What
>> happens if you have 100k units, and the client is reading 100 at a time,
>> and an item gets inserted or deleted near the beginning.   It looks to
>> me like the client would miss a boundary item or see a duplicated item.
>>    (We've addressed this in paging by varying the page size when that
>> happens.)    This seems like it'd be outside of what the folks designing
>> Range were expecting, and so it wouldn't be properly handled. Hoping
>> I'm wrong....
>> ...
>
>
> If-Range. See 
> <http://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7233.html#rfc.section.3.2>.
>

I knew about that, thanks.  That allows one to detect that the resource 
state has changed, but not to safely continue downloading the rest of it 
without unrelated losses.  (In the case of changes to LDP resources, 
there are certain situations where it makes a lot of sense to continue, 
because the change is bounded in predictable ways.)

        -- Sandro

> Best regards, Julian
>

Received on Monday, 8 September 2014 14:48:54 UTC