Re: Headers vs Response Code for 2NN Contents Of Related

On 09/27/2014 05:38 PM, Julian Reschke wrote:
> On 2014-09-27 13:46, Sandro Hawke wrote:
>> We seem to be stalled in discussion of the 2NN Contents Of Related
>> proposal [1]. I'd like to briefly summarize the concerns I've heard and
>> provide summary responses. Then I'd like to sketch an alternative
>> proposal which might be more widely acceptable. It has the particular
>> advantage of not needing IETF consensus to go forward, since it just
>> requires new headers, not a new response code.
>>
>> First, I think these are the main points in the discussion so far:
>>
>> Q. Why do you want a new response code?
>>
>> We have a community of Linked Data users, passing around RDF over HTTP
>> connections, and this is something they want. I'm specifically
>> representing the W3C Linked Data Platform (LDP) WG which wants it for
>> paging, to avoid a roundtrip. Others have said it would be useful for
>> them, including the W3C TAG which says it helps with their httpRange-14
>> issue.
>>
>> Q. Why is one additional roundtrip so important?
>>
>> If you're getting 1000 pages, then obviously adding one roundtrip is a
>> trivial additional cost, but we expect the common behavior to be just
>> looking at the first page. When you look at search results, do you go
>> through every page? No, the response was, "There are a lot of results,
>> here are some", and that's often enough, especially if they're ordered
>> in some useful way. In this case of just looking at a small first page,
>> saving the roundtrip could nearly double the speed.
>>
>> Q. These interactions wont always make full use of caching.
>>
>> True, not with the current cache architecture, they wont. We have some
>> ideas for how to make caching work much better for Linked Data
>> applications, but that can be handled separately.
>>
>> Q. Why not use Range, with a new type of units?
>>
>> That's not the way WebApps are usually written. There are a lot of
>> details that would have to be figured out which are already figured out
>> for next/prev paging, and that's what the developers seem to want. Plus,
>> since the bar for new range units is IETF consensus, we're not
>> optimistic that we'd be able to move forward even if we figured it 
>> all out.
>>
>> Q. Why not use 200 OK + Content Location?
>>
>> 200+CL is defined as returning a representation of the requested
>> resource, but in next/prev paging, each of those pages is conceptualized
>> as its own resource. Logically, something can't be the same resource as
>> its own first page. In practical terms, if a server used 200+CL to
>> return just the first page, how would the client know it had only been
>> sent the first few triples (instead of all of them, as usual)? The
>> Content-Location header is already used is con-neg so it can't also
>> carry this information.
>>
>> Q. Why not use 200+Link?
>>
>> It's true that in LDP paging there are Link headers that would tell the
>> client it got the first page instead of the whole resource, but then
>> we've still misused 200 OK and are sending a representation of a
>> different resource. We'd have to carefully avoid caching, and it's
>> unclear what other things might break by having links change the 
>> semantics.
>>
>>
>> This does however lead to my current proposal, which is that we use a
>> new header (really a pair of headers) for this purpose. The details
>> could be tweaked, but it would be something like this:
>>
>> In general, the purpose and data flow and caching rules are the same as
>> in the 2NN proposal [1]. The syntax differs as follows:
>>
>> (1) the client signals that it implements and wants to use this
>> mechanism by sending something like
>>
>> Please-Follow-Redirects: 303
>>
>> instead of
>>
>> Prefer: contents-of-related
>>
>> The values for this new header would be 3xx codes. Repeated values would
>> mean that multiple kinds of redirects should be followed.
> > ...
>
> Why don't you just make it:
>
>   Prefer: retrieve-contents-of-303-target
>
> (with a more suitable name...)

Hmmm.   What do you think about the rest of the proposal?   Do you 
prefer this header-based design over the response-code based one? Are 
you okay with both or neither or just this one?

On use of Prefer, is there guidance somewhere?   I can't really tell 
where one would use Prefer over a new header.   If Prefer existed, would 
it have been better to make many of the existing request headers be done 
with prefer?  It's easy to see how the Accept* headers and the If-* 
headers could be thought of as client preferences.     Also Range.   And 
Cache-Control.   Even Authorization and Cookie could kind of be seen as 
client preferences on server behavior.

I guess the difference is that Prefer can be dropped by intermediaries 
and, essentially, can never cause any error condition.   So Accepts that 
have a wildcard entry could be prefers.  And the If-*s could be.   
Authorization could not be, since it can result in an error.

Am I getting that right?   I really don't care -- I don't see any 
advantage to Prefer, but I don't see any disadvantage, either.

       -- Sandro


> ?
>
> Best regards, Julian
>

Received on Saturday, 27 September 2014 23:57:21 UTC