[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HTTP, WebDAV, and POST




Lisa Dusseault wrote:




On Jun 6, 2004, at 1:09 PM, John Panzer wrote:

Ken MacLeod wrote:

...

* Although WebDAV does not use POST, there does not seem to be any
  conflict in Atom specifying POST for creating server-located
  resources and at some point using WebDAV actions on the resources
  after they've been created.

+1. I think of these as two separate things that happen to go well together, like chocolate and peanut butter:

(a) Simple creation of resources through binary POST in which the server has complete control of the final URI (option #6);
(b) WebDAV -- or something upwardly compatible with WebDAV -- which allows for client-controlled URIs, moving, deleting, locking, etc.


Microsoft's Exchange 2000 WebDAV engine combines these two in pretty much the way you describe. When the user is creating a new item in a WebDAV-compliant collection and doesn't care what the URL is, as long as it's unique, it uses POST with a request-URI of the target parent collection. The server generates a unique URI inside the WebDAV collection. If the client wishes to choose the URL for a new resource, or if the client wishes to overwrite an existing resource, the client uses PUT instead.

This POST usage isn't canonicalized as part of the standard capabilities of a standard WebDAV collection, but it's a simple extension and one could easily imagine standardizing it.

Sounds good; I'm imagining truly complete control in (a), though -- a server at www.example.com is allowed to accept a POSTed resource and store it anywhere, not just in a predefined collection; for example, it might return a URL http://cdn5.example.com/_res/12458383 in response to a POST to http://example.com/_do/resource_post.


This is basically to allow servers to offload resource serving onto other servers (perhaps caching networks); this could help a lot in the case of service providers which need to store data for millions of users, such as AOL.

John