Specify 303 Location value as first page
authorJohn Arwe
Tue, 29 Jul 2014 16:00:27 -0400
changeset 736 ffda91dd27b7
parent 735 8212abe7dd2d
child 737 34d96d2d6359
Specify 303 Location value as first page
ldp-paging.html
--- a/ldp-paging.html	Tue Jul 29 13:08:53 2014 -0400
+++ b/ldp-paging.html	Tue Jul 29 16:00:27 2014 -0400
@@ -10,6 +10,8 @@
 	
 	DONE: Missing link header for equivalent of ldp:pageOf? Need to verify.  Also we have ldp-paging:pageOf in samples
 			but it doesn't exist in rules or vocabulary doc, oversight?
+	TODO: Sandro 7/29: loosen up restrictions on target of pageSortCriteria link
+	TODO: Once companion documents (best practices, primer) have URLs, link to them.  Search on "companion".
 	TODO: Mine Jim des Riv May 21 email for more content
 	TODO: Example 11 is missing ldp:contains, true?  Omit due to GET on page resource, should make it more clear.
 	TODO: Paging intro: add 3rd example showing header linkage amongst pages and (HEAD on) the base resource.
@@ -1136,7 +1138,7 @@
 		<code>307 Temporary Redirect</code> [[!RFC7231]] or <code>308 Permanent Redirect</code> [[!RFC7238]],
 		as [[RFC7231]] makes clear.  This is critical to a client's ability to distinguish between the representation
 		of a single <a>in-sequence page resource</a> and that of the <a>paged resource</a> when a <a>LDP Paging server</a>
-		uses <a href="#ldpr-status-code">redirection</a> as a way to <a href="#ldpr-pagingGET-only-paging-clients">initiate paging</a>.
+		uses <a href="#ldpr-status-code">redirection</a> as a way to initiate paging.
 	</h2></section>
 
 </section>
@@ -1339,11 +1341,53 @@
 	</div>
 		
 	<section id="ldpr-status-code"><h2 class="normal">
-		<a title="LDP Paging server">LDP Paging servers</a> SHOULD respond 
-		with HTTP status code <code>2NN Contents of Related</code> 
-		to successful <code>GET</code> requests with any <a title="Paged resource">paged resource</a> 
-		as the <code>Request-URI</code> when the request indicates the client's support for that status code [[!2NN]], 
-		although any appropriate code such as <code>303 See Other</code> MAY be used.
+			<a title="LDP Paging server">LDP Paging servers</a> SHOULD NOT
+			initiate paging unless the client has indicated it understands LDP Paging or that it is prepared to 
+			process <code>2NN Contents of Related</code> responses [[!2NN]].
+			<a title="LDP Paging server">LDP Paging servers</a> initiating paging SHOULD respond
+			to successful <code>GET</code> requests with any <a title="Paged resource">paged resource</a> 
+			as the <code>Request-URI</code> in one of the following ways:
+			<ul>
+			<li>
+				If the client supports <code>2NN</code> responses, respond
+				with HTTP status code <code>2NN Contents of Related</code> and the first
+				<a>in-sequence page resource</a>'s representation.
+			</li>
+			<li>
+				If the client supports paging but not <code>2NN</code> responses, 
+				respond with 
+				status code <code>303 See Other</code> and a <code>Location</code> response header that identifies
+				the first <a>in-sequence page resource</a>.
+				The only standard means defined by LDP paging for a client to signal a server that the client
+				understands paging is via the <a href="#ldpp-hints">client preference</a> defined for this purpose;
+				other implementation-specific means could also be used.
+			</li>
+			<li>
+				If the server is willing to provide a non-paged representation, respond
+				with an appropropriate status code (likely <code>200 OK</code>) and the potentially large
+				non-paged representation.
+			</li>
+			<li>
+				Either reject the request, most likely with a <code>4xx</code> status code,
+				or (keeping in mind the note below)
+				initiate paging as described above with a <code>303</code> status code, or
+				choose another status code appropriate to the specific situation.
+			</li>
+			</ul>
+			<blockquote>
+				<em>Non-normative note:</em>
+				<a title="LDP Paging server">LDP Paging servers</a> could choose to make any resource
+				available <em>only</em> as a paged resource.  
+				In so doing, when interacting with clients <em>unaware</em> of LDP Paging, 
+				if the server initiates paging anyway then it runs the risk
+				that an ill-behaved client will automatically follow a 
+				<code>303 See Other</code> redirect and believe via the subsequent
+				<code>200 OK</code> that it has obtained a complete representation of the <a>paged resource</a>
+				rather than of a single <a>in-sequence page resource</a>.
+				<a title="LDP Paging client">LDP Paging clients</a> <a href="#ldpp-client-nofollow-303">will not follow redirects in this way</a>,
+				but some existing HTTP clients are known to treat <code>303 See Other</code> redirects as if they were 
+				equivalent to the original request-URI, despite this being explicitly disclaimed in [[RFC7231]].
+			</blockquote>
 	</h2></section>
 
 	<section id="ldpr-guarantee-show-unchanged"><h2 class="normal">
@@ -1514,9 +1558,14 @@
 			This is one mechanism by which clients know that the resource is one of a sequence of pages.  
 		</h2></section><!-- Was 4.10.2.4 / #ldpr-pagingGET-page-type-reqd -->
 
+		<!-- combined into ldpr-status-code
 		<section id="ldpr-pagingGET-only-paging-clients"><h2 class="normal">
 			<a title="LDP Paging server">LDP Paging servers</a> SHOULD NOT
-			initiate paging unless the client has indicated it understands paging.
+			initiate paging unless the client has indicated it understands LDP Paging or that it is prepared to 
+			process <code>2NN Contents of Related</code> responses [[!2NN]].
+			If the client supports paging but not <code>2NN</code> responses, a server initiating paging SHOULD respond with 
+			status code <code>303 See Other</code> and a <code>Location</code> response header that identifies
+			the URI of the first <a>in-sequence page resource</a> of the <a>paged resource</a>.
 			The only standard means defined by LDP paging for a client to signal a server that the client
 			understands paging is via the <a href="#ldpp-hints">client preference</a> defined for this purpose;
 			other implementation-specific means could also be used.</h2>
@@ -1537,6 +1586,7 @@
 				equivalent to the original request-URI, despite this being explicitly disclaimed in [[RFC7231]].
 			</blockquote>
 		</section>
+		-->
 
 </section>
 
@@ -1704,13 +1754,13 @@
 
 @base &lt;http://example.org/netWorth/nw1/assetContainer/pageSortOrder/&gt; .
 @prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
-<!-- (#SortValueAscending) does not work, because the subject uri would be a blank node -->
+<!-- (#Sort-o.value-Ascending) does not work, because the subject uri would be a blank node -->
 &lt;&gt; 
    a rdf:List;
-   rdf:first &lt;#SortValueAscending&gt; ; 
+   rdf:first &lt;#Sort-o.value-Ascending&gt; ; 
    rdf:rest rdf:nil .
 
-&lt;#SortValueAscending&gt;
+&lt;#Sort-o.value-Ascending&gt;
    a ldp:pageSortCriterion;
    ldp:pageSortOrder ldp:Ascending;
    ldp:pageSortPredicate o:value.
@@ -2088,6 +2138,8 @@
 <!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-paging-20140930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
 <!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-paging-20140730/">Last Call Draft</a></em></blockquote> -->
 <ul>
+	<li>2014-07-29 - Fully specify 303+location's URI (JA) </li>
+	<li>2014-07-29 - Fuss with SortValueAscending value for Sandro (JA) </li>
 	<li>2014-07-29 - Update 6.2.9 to resolve the "add only at the end"/sorted container conflict (JA) </li>
 	<li>2014-07-29 - Remove chunked transfer encoding, which readers were conflating with paging (chunking) (JA) </li>
 	<li>2014-07-29 - Finish Turtle updates for change to Link header to locate sort criteria (JA) </li>