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

On September 8, 2014 10:48:41 AM EDT, Sandro Hawke <sandro@w3.org> wrote:
>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.
>

Oh, sorry for the confusion, I forgot this is irrelevant, since we require servers to never send 2NN to clients unless the client first says it implements it.

      - Sandro

>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 15:40:27 UTC