Subject: [VCARDDAV] Vcarddav: creating new resources

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Oct 2008 14:50:32 +0200

Hi,

currently, the Vcarddav spec requires clients to choose names for new 
cards, and servers to support client-specified names. This is similar to 
CalDAV, and inherited from WebDAV, which doesn't specify a way to create 
a new collection member, but to let the server pick the name.

In AtomPub, the answer to this was: just use POST.

I've been working on a proposal that would allow a WebDAV server to tell 
the client: "look, you can POST to this collection" -- see 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-01.html>.

How about using this for VCardDAV, and, in particular, allow servers to 
reject PUT-to-create requests?

BR, Julian
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Helge Hess <[email-masked]>
Date: Mon, 20 Oct 2008 14:58:03 +0200

On 20.10.2008, at 14:50, Julian Reschke wrote:
> I've been working on a proposal that would allow a WebDAV server to  
> tell the client: "look, you can POST to this collection" -- see <http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-01.html 
> >.
>
> How about using this for VCardDAV, and, in particular, allow servers  
> to reject PUT-to-create requests?

Nothing against an additional POST operation, but I'm against the  
'allow the server refuse PUT-to-create requests' thing.
(Well, if people decide to support that, at the minimum the response  
to such a PUT should explicitly state the fact the POST must be used  
somehow (w/o OPTIONS)).

Thanks,
   Helge
-- 
Helge Hess
http://helgehess.eu/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Oct 2008 15:06:43 +0200

Helge Hess wrote:
> Nothing against an additional POST operation, but I'm against the 'allow 
> the server refuse PUT-to-create requests' thing.
> (Well, if people decide to support that, at the minimum the response to 
> such a PUT should explicitly state the fact the POST must be used 
> somehow (w/o OPTIONS)).

<http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-01.html#rfc.section.4.2>.

BR, Julian

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 20 Oct 2008 09:31:59 -0400

Hi Helge,

--On October 20, 2008 2:58:03 PM +0200 Helge Hess 
<[email-masked]> wrote:

> such a PUT should explicitly state the fact the POST must be used somehow
> (w/o OPTIONS)).

One thing I have seen with a CalDAV server is that the server allows the 
PUT but returns a Location header to tell the client where it actually 
went. So an alternative to the POST;addmember approach is to simply make it 
clear that clients need to check the Location header after a PUT of a new 
resource to verify the actual URI of the new resource. Whilst that still 
forces a client to "guess" a suitable URI to use for the initial PUT, it 
gets around the issue of the client not knowing how to handle the new POST 
behavior.

-- 
Cyrus Daboo

---

From: Helge Hess <[email-masked]>
Date: Mon, 20 Oct 2008 15:44:54 +0200

On 20.10.2008, at 15:31, Cyrus Daboo wrote:
> --On October 20, 2008 2:58:03 PM +0200 Helge Hess <[email-masked] 
> > wrote:
>> 'allow
>> somehow
> One thing I have seen with a CalDAV server is that the server allows  
> the PUT but returns a Location header to tell the client where it  
> actually went. So an alternative to the POST;addmember approach is  
> to simply make it clear that clients need to check the Location  
> header after a PUT of a new resource to verify the actual URI of the  
> new resource. Whilst that still forces a client to "guess" a  
> suitable URI to use for the initial PUT, it gets around the issue of  
> the client not knowing how to handle the new POST behavior.

Yes, this is what *I* also prefer. But there have been really  
loooongish discussions on that :-/

Actually there are two variants:
a) the server returns Location with a 201 (Created)
b) the server returns Location with a 301 (Moved Permanently)

Most do a), but I think Zimbra does b). b) requires that the client  
resubmits the request to the new, server choosen location (though a  
duplicate transfer could be avoided with 100-continue).

BTW: there are even servers which return a new URL on each and every  
change :-) Eg IMAP4 based backend storages. Not that I consider such  
relevant ;-)

Greets,
   Helge

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Oct 2008 15:53:04 +0200

Cyrus Daboo wrote:
> went. So an alternative to the POST;addmember approach is to simply make 
> it clear that clients need to check the Location header after a PUT of a 
> new resource to verify the actual URI of the new resource. Whilst that 
> still forces a client to "guess" a suitable URI to use for the initial 
> PUT, it gets around the issue of the client not knowing how to handle 
> the new POST behavior.

I'd call that a hack. It's certainly nothing the HTTP definition of PUT 
allows.

BR, Julian

---

From: Helge Hess <[email-masked]>
Date: Mon, 20 Oct 2008 15:59:39 +0200

On 20.10.2008, at 15:53, Julian Reschke wrote:
> I'd call that a hack. It's certainly nothing the HTTP definition of  
> PUT allows.

Please, not again :-) Maybe someone has a reference to a past  
discussion at hand? (I don't, but there should be >100 ...)

Please do not use words like 'certainly' on subjects which are clearly  
debatable, and the past has shown that opinions differ a lot on that  
particular issue. No offense :-)

Thanks,
   Helge

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Oct 2008 16:08:19 +0200

Helge Hess wrote:
> Please, not again :-) Maybe someone has a reference to a past discussion 
> at hand? (I don't, but there should be >100 ...)
> 

I do agree that we had that discussion before. On the other hand I 
challenge you to quote text from RFC2616 that allows this behavior.

The right thing to do here is to use a method that has the desired 
semantics, not to bend one which is close.

If CalDAV servers have been known to do this, then this is proof that 
server implementers want this functionality, and implement whatever hack 
is needed to get there.

Please let's not repeat that mistake; do it properly.

BR, Julian

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 20 Oct 2008 10:10:48 -0400

Hi Julian,

> I'd call that a hack. It's certainly nothing the HTTP definition of PUT

2616 says:

   The Location response-header field is used to redirect the recipient
   to a location other than the Request-URI for completion of the
   request or identification of a new resource. For 201 (Created)
   responses, the Location is that of the new resource which was created
   by the request.

That very much implies to me that a PUT that results in a 201 can return 
Location in the way I described. The current httpbis drafts have similar 
wording.

It is true that the definition of PUT does not explicitly mention the 
Location behavior, but the description for Location implies this behavior.

-- 
Cyrus Daboo

---

From: Helge Hess <[email-masked]>
Date: Mon, 20 Oct 2008 16:14:37 +0200

> challenge you to quote text from RFC2616 that allows this behavior.

Its neither explicitly allowed nor forbidden. Reread the past threads  
on pro/contra, really it makes not that much sense to reraise the  
issue in that mailing list.

Section 10.2.2 says this:
---snip---
10.2.2 201 Created
The request has been fulfilled and resulted in a new resource being  
created. The newly created resource can be referenced by the URI(s)  
returned in the entity of the response, with the most specific URI for  
the resource given by a Location header field.

...

---snap---

Section 9.6 says:

---snip---

If the server desires that the request be applied to a different URI,

it MUST send a 301 (Moved Permanently) response; the user agent MAY  
then make its own decision regarding whether or not to redirect the  
request.

---snap---

Which is basically the Zimbra behaviour I think.

The spec is IMHO not consistent/clear on the issue. Can be read many  
ways.

Thanks,

   Helge

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Oct 2008 16:19:30 +0200

> Location behavior, but the description for Location implies this behavior.

2616 says for PUT:

"The PUT method requests that the enclosed entity be stored under the 
supplied Request-URI. If the Request-URI refers to an already existing 
resource, the enclosed entity SHOULD be considered as a modified version 
of the one residing on the origin server. If the Request-URI does not 
point to an existing resource, and that URI is capable of being defined 
as a new resource by the requesting user agent, the origin server can 
create the resource with that URI. If a new resource is created, the 
origin server MUST inform the user agent via the 201 (Created) response."

So if the server does not store the resource under the supplied 
Request-URI, it has not done what the client asked for.

It goes on saying:

"In contrast, the URI in a PUT request identifies the entity enclosed 
with the request -- the user agent knows what URI is intended and the 
server MUST NOT attempt to apply the request to some other resource. If 
the server desires that the request be applied to a different URI, it 
MUST send a 301 (Moved Permanently) response; the user agent MAY then 
make its own decision regarding whether or not to redirect the request."

Really, it's a hack. It may work with some clients, but that's it.

If you really thing this is a legal use of PUT, please come over to the 
httpbis WG and ask for clarification :-).

BR, Julian

---

From: Helge Hess <[email-masked]>
Date: Mon, 20 Oct 2008 16:25:35 +0200

On 20.10.2008, at 16:19, Julian Reschke wrote:
> It goes on saying:
> "In contrast, the URI in a PUT request identifies the entity  
> enclosed with the request -- the user agent knows what URI is  
> intended and the server MUST NOT attempt to apply the request to  
> some other resource. If the server desires that the request be  
> applied to a different URI, it MUST send a 301 (Moved Permanently)  
> response; the user agent MAY then make its own decision regarding  
> whether or not to redirect the request."

Do I read your quoting right, that status 301 + Location after a PUT  
would be fine with you?

If so, lets standardize on that behaviour and turn the MAY into a MUST  
for CalDAV/CardDAV servers. Instead of creating a specific POST ...

Thanks,
   Helge

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 20 Oct 2008 10:28:59 -0400

Hi Helge,

> for CalDAV/CardDAV servers. Instead of creating a specific POST ...

The trouble is a server may not know what the actual URI is going to be 
until after it has stored the resource in the backend calendar store, so it 
can't return a 301 with a valid Location header. That is the situation in 
which only POST;addmember will suffice. That is also why people have 
"hacked" 201 + Location.

-- 
Cyrus Daboo

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Oct 2008 16:43:33 +0200

Helge Hess wrote:
>> server MUST NOT attempt to apply the request to some other resource. 
>> request."

I don't think it's a good idea (as I assume that existing clients will 
be confused), but at least it's something the spec allows.

> for CalDAV/CardDAV servers. Instead of creating a specific POST ...

Could you elaborate what's wrong with using POST for it?

BR, Julian

---

From: Helge Hess <[email-masked]>
Date: Mon, 20 Oct 2008 16:55:25 +0200

On 20.10.2008, at 16:43, Julian Reschke wrote:
>> Do I read your quoting right, that status 301 + Location after a  
>> PUT would be fine with you?
> I don't think it's a good idea (as I assume that existing clients  
> will be confused), but at least it's something the spec allows.

You are right, 201+location works much better with existing clients ;-)

Anyways: chances are obviously better that 301+location works with  
existing clients than some completely new invention.

>> If so, lets standardize on that behaviour and turn the MAY into a  
>> MUST for CalDAV/CardDAV servers. Instead of creating a specific  
>> POST ...

New method for something which already exists. Bad interoperability  
with existing clients. Dislike of using the catch-all POST operation  
when the PUT+location combo is proven to work perfectly fine in da  
real world.

Thanks,
   Helge

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Oct 2008 17:05:54 +0200

Helge Hess wrote:
>>> MUST for CalDAV/CardDAV servers. Instead of creating a specific POST ...
> New method for something which already exists. Bad interoperability with 
> existing clients. Dislike of using the catch-all POST operation when the 
> PUT+location combo is proven to work perfectly fine in da real world.

POST is not a new method.

PUT+Location definitively does *not* work everywhere; I'm sure of that 
because the WebDAV client code I've written in the past certainly won't 
understand it.

If the catch-all semantics of POST are a problem, then one way to handle 
  this is to offer the client enough information about what POST 
semantics are implemented. For instance, AtomPub does this by requiring 
the more specific behavior for the Atom feed URIs it exposes. My 
proposal (for WebDAV) does the equivalent; it exposes the URI for 
"add-member" POSTs on the wire (PROPFIND or DAV:error), so a client can 
rely on the desired semantics.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Oct 2008 11:32:03 +0100

> rely on the desired semantics.

For the record, we *did* move the discussion over to the httpbis WG's 
mailing list; see thread at 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2008OctDec/thread.html#msg44> 
in general, and Roy's message at 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2008OctDec/0096.html> 
in particular.

BR, Julian