The Hypertext Transfer Protocol (HTTP) Status Code 2NN (Contents of Related)World Wide Web Consortium32 Vassar St.CambridgeMA02140USAeric@w3.orghttp://www.w3.org/People/Eric/ericP-foaf#ericPHTTPredirectstatus code
This document specifies the additional HyperText Transfer Protocol (HTTP) Status Code 2NN (Contents of Related).
It also specified a Prefer header value "contents-of-related" which clients can use to indicate that they can accept 2NN responses.
Distribution of this document is unlimited.
Comments should be sent to the W3C Technical Architecture Group mailing list at www-tag@w3.org (public archive) and the Linked Data Platform mailing list at public-ldp-comments@w3.org (public archive).
The latter list may be joined by sending a message with subject "subscribe" to public-ldp-comments-request@w3.org.
XML versions, latest edits, and the issues list for this document
are available from .
Test cases related to redirection in general and the status code 2NN in particular can be found at as a template.
HTTP 2xx status codes indicate that the client's request was successfully received, understood, and accepted.
The 2NN status code response asserts that the Location response header identifies a resource related to the requested resource and that the response contents are a representation of that related resource.
The 2NN response bypasses the extra round trip required for use cases conventionally solved with a 303 (See Other) response followed by the client performing a second GET on the target of that redirect.
For example, 2NN streamlines these interactions which conventionally involve a server response with a Location header referencing the information needed by the client:
An HTTP client performs a GET on a resource which is not an information resource.
The server responds with a 303 and the client performs a second GET to retrieve an information resource related to the previous resource.
(This idiom is frequently used to provide information about a resource while keeping that resource distinct from any page describing it.)
An HTTP server responds to a POST request by creating a new resource and returning a 303 to redirect the client to that new resource.
(This use case is described in .)
The resource requested in a GET is prohibitively large to serve and the server instead responds with a redirect to the beginning of a series of resources paginating the initial resource.
The paginating resources are interlinked with the 'prev' and 'next' link headers described in .
A client has requested a Web application and the server responds with a multi-document response including e.g. HTML, images, CSS, Javascript and data for the web application.
A client performs a POST which creates a new resource.
The server has requested a Web application and the server responds with a multi-document response including e.g. HTML, images, CSS, Javascript and data for the web application.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
The 2NN (Contents of Related) status code indicates that the server is providing a response for the request method (e.g. GET or POST) performed on the URI in the Location response header, henceforth called the "related resource".
The "expected response" is the response that the client would have received had it performed a GET on the related resource.
If the initial request method is HEAD, the expected response has no message body (see RFC 7231 4.3.2. HEAD ).
By returning a 2NN status code, the server asserts that:
The expected response has a status code of 200.The expected response has no Location header.
The 2NN response is the same as the expected response with the following changes:
The status code is 2NN (instead of 200).A Location header identifies the related resource.
As with Content-Location, such a claim can only be trusted if both identifiers share the same resource owner, which cannot be programmatically determined via HTTP (see RFC 7231 3.1.4.2. Content-Location ).
For caching purposes, see below.
For purposes other than caching, the response is interpreted as if the response code were 200 and the effective request URI were the related resource.
This defines the semantics for all current headers other than Location, as well as future headers defined as extensions to HTTP 1.1.
A 2NN MUST NOT be used if the expected response includes a Location header.
The following example demonstrates the use of 2NN responses to streamline the creation of new resources as described by .
The 2NN response is generic; it can be used for any use case where the server expects a client to dereference a Location header, for example, image tiling or packaging web applications.
Client request:Server 2NN response:; rel="next"
Content-Location: http://bigco-static.example/p1.ttl
Content-Length: 145
"Here is everything we know about this giant resource...".
]]>
Here, the related resource is http://bigco-static.example/p1 and the expected response is same as the Server 2NN response above, but with a 200 status code and no Location header.
The above example communicates the same response as the following client-server exchanges where the client performs an operation on a resource, the server responds with a 303, and the client performs a GET (or HEAD) on the resource in the Location header of the servers 303 response:
Client request:Server 303 response:303