W3C home > Mailing lists > Public > www-tag@w3.org > August 2007

Re: ISSUE-57: The use of HTTP Redirection

From: Ed Davies <edavies@nildram.co.uk>
Date: Mon, 27 Aug 2007 11:51:03 +0100
Message-ID: <46D2AC97.7020707@nildram.co.uk>
To: Technical Architecture Group WG <www-tag@w3.org>

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?

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 Monday, 27 August 2007 10:53:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:17 UTC