Arnaud Quillaud | 2 Nov 11:15 2009
Picon

allow use of multipart/form-data in draft-reschke-webdav-post

Hello,

Late comment on draft-reschke-webdav-post:

Browser based applications are not allowed to upload files from the 
client filesystem by any mean other than using an HTML form containing a 
file param and an enctype of multipart/form-data. As a consequence, 
those applications have no way to upload local files to a WebDAV 
repository using PUT (my knowledge of browser based technologies is 
rather limited but I have found at least a few references to this 
limitation).

http://tools.ietf.org/html/draft-reschke-webdav-post could partially 
solve this issue by simply allowing a multipart/form-data containing a 
single subpart to be POSTed.

Modifying a resource by uploading it again would still not be possible 
of course but that can be somehow workarounded.

Arnaud Quillaud

Petr Tomasek | 2 Nov 20:36 2009
Picon

Re: allow use of multipart/form-data in draft-reschke-webdav-post

On Mon, Nov 02, 2009 at 11:15:02AM +0100, Arnaud Quillaud wrote:
> Hello,
> 
> Late comment on draft-reschke-webdav-post:
> 
> Browser based applications are not allowed to upload files from the 
> client filesystem by any mean other than using an HTML form containing a 
> file param and an enctype of multipart/form-data. As a consequence, 
> those applications have no way to upload local files to a WebDAV 
> repository using PUT (my knowledge of browser based technologies is 
> rather limited but I have found at least a few references to this 
> limitation).
> 
> http://tools.ietf.org/html/draft-reschke-webdav-post could partially 
> solve this issue by simply allowing a multipart/form-data containing a 
> single subpart to be POSTed.
> 
> Modifying a resource by uploading it again would still not be possible 
> of course but that can be somehow workarounded.
> 
> Arnaud Quillaud

Wouldn't it be easier (and a cleaner solution) if the browsers just supported PUT/WebDAV?

P.T.

--

-- 
Petr Tomasek <http://www.etf.cuni.cz/~tomasek>
Jabber: butrus <at> jabbim.cz
SIP: butrus <at> ekiga.net
(Continue reading)

Arnaud Quillaud | 2 Nov 21:04 2009
Picon

Re: allow use of multipart/form-data in draft-reschke-webdav-post

On 11/2/09 8:36 PM, Petr Tomasek wrote:
> On Mon, Nov 02, 2009 at 11:15:02AM +0100, Arnaud Quillaud wrote:
>    
>> Hello,
>>
>> Late comment on draft-reschke-webdav-post:
>>
>> Browser based applications are not allowed to upload files from the
>> client filesystem by any mean other than using an HTML form containing a
>> file param and an enctype of multipart/form-data. As a consequence,
>> those applications have no way to upload local files to a WebDAV
>> repository using PUT (my knowledge of browser based technologies is
>> rather limited but I have found at least a few references to this
>> limitation).
>>
>> http://tools.ietf.org/html/draft-reschke-webdav-post could partially
>> solve this issue by simply allowing a multipart/form-data containing a
>> single subpart to be POSTed.
>>
>> Modifying a resource by uploading it again would still not be possible
>> of course but that can be somehow workarounded.
>>
>> Arnaud Quillaud
>>      
> Wouldn't it be easier (and a cleaner solution) if the browsers just supported PUT/WebDAV?
>    
It might be cleaner but definitely not easier to get this standardized 
on all browsers (and have all legacy browsers disappear).

Found a page describing the behavior of different browsers at 
(Continue reading)

Julian Reschke | 3 Nov 19:30 2009
Picon
Picon

Re: allow use of multipart/form-data in draft-reschke-webdav-post

Arnaud Quillaud wrote:
> Hello,
>
> Late comment on draft-reschke-webdav-post:
>
> Browser based applications are not allowed to upload files from the
> client filesystem by any mean other than using an HTML form containing
> a file param and an enctype of multipart/form-data. As a consequence,
> those applications have no way to upload local files to a WebDAV 
> repository using PUT (my knowledge of browser based technologies is 
> rather limited but I have found at least a few references to this 
> limitation).
>
> http://tools.ietf.org/html/draft-reschke-webdav-post could partially
> solve this issue by simply allowing a multipart/form-data containing a 
> single subpart to be POSTed.

It could. However I'm not entirely happe with special casing a single mime type.

An alternative would be to define a *second* URI that would accept POST requests from HTML forms.

> Modifying a resource by uploading it again would still not be possible > of course but that can be somehow workarounded.

Orthogonal problem...

Best regards, Julian

--

-- 
DSL-Preisknaller: DSL Komplettpakete schon für 16,99 Euro mtl.!*
http://portal.gmx.net/de/go/dsl02
(Continue reading)

Cyrus Daboo | 6 Nov 02:50 2009

draft-reschke-webdav-post-04

Hi,
I have heard from some implementors that they would like collection 
creation to also be part of this draft. In particular, CalDAV and/or 
CardDAV clients creating calendars or address books would prefer to leave 
specification of the resource name to the client.

Proposal:

- Add a DAV:add-collection property containing a URI (which must be 
different than DAV:add-member)
- A POST on that URI creates a collection within the parent collection, 
with a server chosen resource name
- If the POST contains an XML body with DAV:mkcol as the root element, then 
that body is interpreted the same way as MKCOL ext.

Comment:
For the Example in section 3.4 it might be better to have the request body 
contain text that is different from that in the Slug header to make it 
clear where the name the server chose is coming from.

--

-- 
Cyrus Daboo

_______________________________________________
ietf-caldav mailing list -- ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Julian Reschke | 10 Nov 15:21 2009
Picon
Picon

Re: draft-reschke-webdav-post-04

Cyrus Daboo wrote:
> Hi,
> I have heard from some implementors that they would like collection 
> creation to also be part of this draft. In particular, CalDAV and/or 
> CardDAV clients creating calendars or address books would prefer to 
> leave specification of the resource name to the client.
> 
> Proposal:
> 
> - Add a DAV:add-collection property containing a URI (which must be 
> different than DAV:add-member)
> - A POST on that URI creates a collection within the parent collection, 
> with a server chosen resource name
> - If the POST contains an XML body with DAV:mkcol as the root element, 
> then that body is interpreted the same way as MKCOL ext.

Sounds good to me. Before I make this change -- the doc already being in 
state "publication requested" -- does anybody have a problem with this? 
(Note it's totally optional; a server that doesn't want to support this 
simply wouldn't expose the property).

> Comment:
> For the Example in section 3.4 it might be better to have the request 
> body contain text that is different from that in the Slug header to make 
> it clear where the name the server chose is coming from.

Good point. Fixed in 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html>.

Best regards, Julian
(Continue reading)

Julian Reschke | 19 Nov 12:21 2009
Picon
Picon

Re: I-D Action:draft-brown-versioning-link-relations-02.txt

(FYI)

Julian Reschke wrote:
> (FYI)
> 
> This draft defines five link relations that can be used to navigate 
> between versions, editable resources and version histories.
> 
> The main change compared to the previous draft is that we changed the 
> terminology so that it can be used for CMIS/AtomPub, WebDAV, and JCR 
> (Java Content Repository).
> 
> I have also added an informative appendix that shows how the link 
> relation could be used inside the HTTP "Link" header in the context of 
> WebDAV.
> 
> Feedback appreciated,
> 
> Julian
> 
> 
> Internet-Drafts <at> ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>>
>>     Title           : Link Relations for Simple Version Navigation
>>     Author(s)       : A. Brown, et al.
>>     Filename        : draft-brown-versioning-link-relations-02.txt
>>     Pages           : 9
>>     Date            : 2009-11-19
(Continue reading)

Arnaud Quillaud | 19 Nov 18:20 2009
Picon

new webdav sync draft

Hello,

I have just submitted a new version of the webdav sync draft ( 
http://www.ietf.org/id/draft-daboo-webdav-sync-02.txt ).

This draft addresses several, if not all, of the comments from the last 
version (change history is part of the draft).

The open issues section still contains 2 significant items, to be discussed.

Comments welcome...

Arnaud Quillaud

Julian Reschke | 20 Nov 08:08 2009
Picon
Picon

Re: [VCARDDAV] [caldav] new webdav sync draft

Andrew McMillan wrote:
> ...
> In 4.2, under 'Marshalling' it states:
> 
>         The request URI MUST be a collection.  The request body MUST be
>         a DAV:sync-collection XML element (see Section 6.1), which MUST
>         contain one DAV:sync-token XML element, and optionally a
>         DAV:propstat XML element.
> ...

Nit: s/be a collection/identify a collection/

I confess I haven't looked at this closely yet, but why is it defining 
elements in the DAV: namespace?

BR, Julian

Cyrus Daboo | 20 Nov 15:11 2009

Re: [caldav] [VCARDDAV] new webdav sync draft

Hi Julian,

--On November 20, 2009 8:08:41 AM +0100 Julian Reschke 
<julian.reschke <at> gmx.de> wrote:

>>         The request URI MUST be a collection.  The request body MUST be
>>         a DAV:sync-collection XML element (see Section 6.1), which MUST
>>         contain one DAV:sync-token XML element, and optionally a
>>         DAV:propstat XML element.
>> ...
>
> Nit: s/be a collection/identify a collection/
>
> I confess I haven't looked at this closely yet, but why is it defining
> elements in the DAV: namespace?

This is generic to WebDAV, not specific to CardDAV or CalDAV. So use of 
DAV: is justified.

--

-- 
Cyrus Daboo


Gmane