- From: John Arwe <johnarwe@us.ibm.com>
- Date: Thu, 31 Jul 2014 13:23:07 -0400
- To: "public-ldp-wg@w3.org Platform WG" <public-ldp-wg@w3.org>
- Message-ID: <OFC21C979D.EE5B5EAC-ON85257D26.005BCC50-85257D26.005F80EE@us.ibm.com>
> > [going waaaaay out on a new branch from that point...thinking out loud] > > If the client supports 2NN, the server could I think legally > return 2NN+new-first-page in this case. > > Else If the client supports LDP paging, '303 to the new first > page' could be made to work, with changes below > > Else 4xx seems required, and the headers won't help it anyway, > although it is true that the only way a non-paging-aware client > could get to this case is if it was given "a URI" that happened to > be a page URI. > > > > changes for "303 to restart traversal", might well also apply to 2nn case: > > - paging client needs a way to tell that what it got is *the > first* page in particular (it requested the n>=1st page), which > currently is a known only via the client's point in the interaction > not via response content; trivial to solve with a Link: <303- > location-uri>; rel='first' header. > > - that might serve to distinguish sufficiently between "sequence > abandoned" (this new 303-on-a-page case) and other error cases > apropos your original comment above ... I think the only new > *normative* text would be for the link on 303. > > > "the link" is the link header sample you show above? yes: Link: <303-location-uri>; rel='first' > To play it > out, the "303 to restart traversal" client would have to be smart > enough to compare Link: <303-location-uri>; rel='first' and Location > header uri, if they match, then "this is not the page you were > looking for, give up on paging, and start here". Upon receipt of a 303 or 2NN, any *LDP Paging client* knows "this is not the page you were looking for" via 5.1.6. Full stop. How it reacts to that is up to the client implementation. Assuming it wishes to restart traversal, it's very much like the pattern in chapter 4: 1: It is free to GET paged-resource-URI and start traversal from the beginning, with no further optimization. 2: If it wishes to optimize by avoiding that GET, then it can see if the 303 Location-header-URI is the first page. I suggested Link: <303-location-uri>; rel='first' as one way that we could define for doing so. 3: If it is 2NN-capable, then the server could allow the client to avoid both the GET from #1 and the GET of first-page-URI by responding with 2NN and the contents of the first page. This has the same "is the Location URI the 'first' page?" problem as #2, and presumably the same solution. > A client not aware > of this, just following links and consuming RDF, could keep going on > for a while with a bunch of redundant stuff (not sure this something > we can completely avoid but just pointing it out). A client not aware that 303 means they're getting the URI of a resource different from what they requested is not an LDP Paging client (violates 5.1.6). A client not aware that 2NN means they're getting the URI of a resource different from what they requested is an LDP Paging client but violates the 2NN spec, assuming the server behaves and only initiates paging-using-2nn when the client has asserted it's 2nn-capable. Either way one of the parties is violating one of the specs. It is certainly true that not all existing HTTP clients comply with 5.1.6 and ~zero are 2nn-aware, so the fact that they're not LDP Paging clients while true is not the whole story by any means. Specifying something conditional that makes a possibly large existing client base less likely to work incorrectly could be a good trade-off. > .... I kind of like > 410-Gone approach instead, if client had previous copies of first/ > last/next, it could check those and check the paged resource. 410-Gone has the obvious advantage that no client can possibly get something unexpected, since they're all getting nothing. Hence they can't wander off doing foolish things, regardless of their LDP Paging or 2NN awareness/ignorance/malfeasance. The chapter-4-ish optimization possibilities I laid out above are still possible, simply less likely to be implemented. Since they're still possible, and I'm honestly not sure how much effort it's worth to optimize restarting paging (for either party), people might well prefer to add the SHOULD at this point. Having convinced myself they are still possible, I'm content to either have the should or not, and leave any of the optimizations above out of the spec regardless; if it becomes something important, it's still here and it can be put in .whatever. Best Regards, John Voice US 845-435-9470 BluePages Cloud and Smarter Infrastructure OSLC Lead
Received on Thursday, 31 July 2014 17:23:39 UTC