http URIs and methods

There is a problem with http URI implying GET as a default method and not
allowing any other method for retrieval.
Ex 1:
You can deference a http URI by doing a GET, you will get the body you
expect, and some metadata on both the entity served, some connection-level
properties as well as some others (like Date).
Thos can be seen as metadata. How can we access those metadata as a first
class representation (ie: using GET)? In the general case, you won't have
those metadata accessible via GET using a constructed URI, or a linked
URI. Also there is no way to specify that a URI shoudl be deferenced using
HEAD instead of GET.

Ex 2:
Robots.txt (and can be extended to metadata/policies)
Currently, favicon, robotx.txt and p3p can be stored in well known
location which is of course bad per URI opacity axiom.

rfc 2616 defines OPTIONS (sec 9.2) and have a hook to send/receive a body
that may contain whatever another specification wants to define. It is
then easy to imagine defining per-URI information targeted at robots,
icons location, P3P policy or whatever. Also, OPTIONS * refers to the
server in general, so you might put site-wide data here. (for now OPTIONS
only returns the methods allowed for a resource (or implemented by the
server).

This seems like a perfect way to replace robots.txt and other well known
locations, however how can that information be addressed?
It can't once again because the URI doesn't have a way to embed the method
in it, defaulting to GET.

How feasible would be something like:

http{OPTIONS}://www.example.com  to do OPTIONS * HTTP/1.1 ...
http{HEAD}://www.example.com/ to do HEAD / HTTP/1.1 ...

This does not address the metadata of metadata [of metadata]* issue, of
course.
Thanks,

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

Received on Friday, 5 March 2004 05:59:54 UTC