Headers vs Response Code for 2NN Contents Of Related

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.

(2) the server which chooses to use this mechanism (and MUST only do this if the client requested it) responds including these headers:

    Redirect-Followed: 1;303 See Other;<http://example.org/other-content>
    Vary: Please-Follow-Redirects

instead of

    2NN Contents of Related
    Location: http://example.org/other-content

The values for this new header would be triples of (redirection sequence number, redirection response code, new location).  Repeated values must have distinct sequence numbers, and mean that multiple redirection steps were taken.  The actual response code, and all the other headers, will be from the final location, the one whose representation is actually returned and whose URI is in the highest-numbered Redirect-Followed result.

Thoughts?   I believe this is on the agenda for the W3C TAG meeting this coming week, so an early response would be helpful.

A simplification could be that this is only for 303, and it only reports the last hop if multiple redirects were followed.   But if we're going to add this, it seems to me it could also be useful for 301 and 307.  Or is it better not to touch that stuff?   Let me know.

      -- Sandro

[1] https://tools.ietf.org/html/draft-prudhommeaux-http-status-2nn-00