Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00]

Jamie Lokier wrote:
> Julian Reschke wrote:
>>>>Because in general, I will have no idea what the server will do with 
>>>>the POST.
>>>Hmm...the meaning of POST is that the server will process the message. 
>>>If you receive a 201,
>>>the server has created a resource.
>>But *what* does it contain? In general, I can not assume it will store 
>>the entity as sent (like PUT).
>                       ^^^^^^^^
> You cannot assume PUT will store the entity as sent either.
> Read section 5.4 "Source Resources and Output Resources" in RFC 2518, WebDAV.
> (That part's not specific to WebDAV; it's a just a good explanation).

In fact, it says:

"However, if remote editing of the source resource(s) is desired, the 
source resource(s) should be given a location in the URI namespace. This 
source location should not be one of the locations at which the 
generated output is retrievable, since in general it is impossible for 
the server to differentiate requests for source resources from requests 
for process output resources."

>>From the client's point of view, once you have PUT an entity, in
> general you have no way to retrieve that exact entity.  Many servers
> will process the resource you created to produce the response to GET,
> instead of merely returning the entity you sent earlier.
> Because you can't necessarily retrieve the entity sent, you can't make
> assumptions about what the server stores.  It might store only part of
> what you sent, or a transformed version.  What it actually stores --
> and the side effects of doing so -- are quite open.

You keep saying this, but it would be nice if you could point out where 
that kind of behaviour is described. RFC2616 says:

"The PUT method requests that the enclosed entity be stored under the 
supplied Request-URI."

And that's certainly what today's WebDAV servers implement and WebDAV 
clients do expect.

Best regards, Julian

<green/>bytes GmbH -- -- tel:+492512807760

Received on Thursday, 17 February 2005 18:48:27 UTC