Replacing PROPFIND with GET

> Sure. However, I yet have to see a practical proposal how
> 
> a) the "properties" URI for a given resource would be detected and
>
> b) how the various PROPFIND functionalities would map to headers (or query
> parameters).

Roy had some good ideas about this last year.  This was during my "ok,
I know parts of WebDAV don't feel quite right, but I can't put my finger
on it" phase.  Clarity ensued after Roy posted this;

http://www.xent.com/pipermail/fork/2001-September/004712.html

I'll paste the relevant portion here.

] What I would have done (and this was proposed at an early DAV meeting) is
] define a single resource metadata field for HTTP responses that gave a URI
] prefix for operations on properties of that resource.  E.g.,
] 
]    Properties: "http://example.com/this_resource;props"
] 
] and then simply define that namespace in the same way as old server-side
] image maps were defined.  You could then do
] 
]    GET http://example.com/this_resource;props?lock HTTP/1.1
] 
] to find out if the resource has a lock, or
] 
]    PUT http://example.com/this_resource;props?lock HTTP/1.1
] 
] to demand one for yourself.  Note that the entire URI prefix is determined
] by the origin server, so the properties might even be on a different server
] than the resource.  And if you just want a list of all properties, then
] 
]    GET http://example.com/this_resource;props HTTP/1.1
] 
] will do just fine.  Of course, that assumes a standardized namespace for
] property names, such that "lock" has meaning to both client and server,
] to which some people seem to be allergic.
] 
] That one level of indirection allows all properties to be resources and
] solves the nasty cruft added by DAV for ACLs and versioning.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Saturday, 30 March 2002 15:22:45 UTC