Change Proposal 25

Summary

The proposal to change JAR's draft is to allow, for those who insist on using hashless HTTP URIs for things other than the document which is returned by the URI, to address the inefficiency of the 303 redirect method, an alternative using a 200 status with a new HTTP header (say "Document:") on the response message.

Rationale

The HTTP-Range-14 decision was made in order to respond to a requirement to be able to use a hashless HTTP URIs for an arbitrary thing, not just an Information Resource, and to retrieve a representation about that thing.

A pattern proposed was the use of a 303 See Also redirect, but that has painful performance problems.

The requirement can be met by an alternative pattern, in which a 200 status response is used, but with a header.

Details

There follows a set of edit instructions, specific enough that they can be applied without ambiguity.

Replace, in section 4.2, the paragraph

If there is a nominal representation Z from the probe URI, then the client may consider this state of affairs as equivalent to the existence of a nominal URI documentation carrier for the probe URI that says that Z is a current representation of the resource identified by the probe URI, and, moreover, that the identified resource is an "information resource" (see below).

with the two paragraphs:

If there is a nominal representation Z from the probe URI, containing the HTTP header "Document: W", where W is a URI expressed relative to the request URI, then the client may consider this state of affairs as equivalent to the existence of a nominal URI documentation carrier for the probe URI that says that Z is a current representation of the information resource identified by W (see below).
Otherwise, if there is a nominal representation Z from the probe URI, then the client may consider this state of affairs as equivalent to the existence of a nominal URI documentation carrier for the probe URI that says that Z is a current representation of the resource identified by the probe URI, and, moreover, that the identified resource is an "information resource" (see below).

Impact

Documentation such as "Cool URIs.. " will need to be updated

The server operator who insisted on hashless HTTP URIs will be able (and expected with time) to move to this pattern.

The 303 method will still be available to existing servers.

Positive Effects

Servers will not need to configure the response status number, only a header, which is is often easier.
The round-trip count for looking up such probe URIs will be reduced
The server load will be reduced
The client wait will be reduced
Servers will be more inclined to use the semantic web in a compatible way, and so hopefully abuse will be reduced.

Negative Effects

Client code for RDF systems will have to be modified to reflect this change.
Existing RDF code which is unaware of the header will end up with inconsistent conclusion that the probe URL identifies both the thing it does identify and also the document, which will be an error.

Conformance Classes Changes

Describe what conformance classes will have to change.

Risks

There is a risk that people misuse the pattern to return the same document <W> which contains a description of many things <U1> <U2> .., <Un>. This will cause a naive client needing to look up <U1> <U2> .., <Un> to do n retrievals, needing of order n^2 bandwidth. For these situations, hash URIs obviously are a preferred pattern.

References

* The List TagIssue57Responses.
* The list of HTTPURIUseCases.