Re: ISSUE-57: The use of HTTP Redirection

On 2007-08 -27, at 06:51, Ed Davies wrote:

>
> Stuart Williams wrote:
>> At their meeting in 16th July 2007 [1] the TAG resolved to create  
>> a new issue, HttpRedirections-57 as a response to a community  
>> request [2] that we give further consideration to the use of the  
>> HTTP 303 status codes *and* other possible mechanisms of obtaining  
>> a description of a resource (typically a non-information resource)  
>> where the referenced resource is not capable of providing  
>> representations
>> of itself.
>
> Why is this issue limited to resources which are not capable of
> providing representations of themselves?

Often, people use the term "non-information resource" to mean "some  
resource,
not necessarily an information resource".

The use of HTTP 303 is designed for use with any resource,
not contingent on it not being an information resource.

For example, when CERN decided for social reasons not to serve the  
original
material for http://info.cern.ch/hypertext/WWW/TheProject
they put up a page saying "This is not served any more but a snapshot  
of it
is available elsewhere".  A 303 would be a reasonable redirect for  
that, I think.
A 301 or 302 would not as the client would think it had a valid  
representation of the original page.
Similarly, 303 would allow a server to say "I could give you a  
representation of that
resource but I won't as it is huge and instead you should query it  
using the following SPARQL endpoint."

- - -

That said, the question of how to ask for metadata about an Information
Resource still stands, below.

The HEAD request is specifically designed in HTTP to ask for metadata  
but not the
representation.  It would seem strange not to use it.
Discussing this with the Tabulator developers the other day the  
following ideas
turned up:

1.
	Link:  foo.html.meta; rel=meta

This is a header which was designed to exactly echo the HTML <link>  
element.
In this case it provides information that metadata about the thing  
requested is identified by the relative URI  foo.html.meta.
This builds on existing practice most closely.



2.  A more general sem-webby new header could allow arbitrary  
predicate, object pairs:

	Property:  <http://dc/title>  "Moby Dick"

	Property:  <http://www.w3.org/2007/ont/link#editSPARQLEndpoint>  <../ 
foo.sparql>

	Property:  <http://rating.example.org/nudity>  0


3. We could invent new headers which allow bits of N3, even:

	N3: @prefix dc:  <...>.
	N3: @prefix foaf:  <...>.
	N3: <> dc:title "Moby Dick"; is foaf:primaryTopic of [foaf:name  
"Moby Dick"].
	N3: rdfs:seeAlso meta.rdf

(As HTTP headers are unordered, the @prefix lines would have to be  
deemed to precede any other lines)

These flexible hooks into RDF would allow new protocols to be defined  
and played with.

Tim BL


> Suppose I access RFC 2068 [1] and think, hmm, this web stuff
> looks interesting, I wonder if it'll catch on?  My first thought
> would be to check on the standardization state of RFC 2068 and
> whether or not it's been obsoleted.  The RFC editors are pretty
> good about not messing with published documents so they don't
> update the text with this information, and anyway it is plain
> text so it's difficult for my browser plugins to take me directly
> to the relevant information (it seems to be a bit much to expect
> a few lines of JavaScript to work out the meaning of 'Please refer
> to the current edition of the "Internet Official Protocol
> Standards" (STD 1) for the standardization state and status of
> this protocol.').
>
> What I'd like to have my browser do is ask the server for some
> metadata about the document - i.e., to get the URI I would get
> back in a 303 if this was a non-information resource.
>
> In general, there are a number of resource types and content
> types for which the author cannot or does not want to include
> metadata or links to metadata in the returned entity but for
> which it would be useful to be able to provide such data.
>
> Two mechanisms spring to mind.  One would be to add a new
> method to HTTP, GET-META perhaps, which either returns the
> metadata directly or its URI. (I'm not sure whether it would
> be best: to allow one, the other or either.)  Another would
> be to add a standard response header (SeeAlso:, perhaps)
> which could be used with normal GET or HEAD methods and which
> would contain the URI of the metadata.  However, maybe
> there's a less intrusive way to get this effect.
>
> [1] http://www.ietf.org/rfc/rfc2068.txt
>

Received on Tuesday, 28 August 2007 15:43:28 UTC