headers
Arnaud Quillaud | 2 Nov 2009 11:15
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
Permalink | Reply | 3 comments |
headers
Petr Tomasek | 2 Nov 2009 20:36
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)

Permalink | Reply | 1 comment |
headers
Arnaud Quillaud | 2 Nov 2009 21:04
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)

Permalink | Reply | 0 comments |
headers
Julian Reschke | 3 Nov 2009 19:30
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)

Permalink | Reply | 0 comments |
headers
Julian Reschke | 19 Nov 2009 12:21
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)

Permalink | Reply | 0 comments |
headers
Arnaud Quillaud | 19 Nov 2009 18:20
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
Permalink | Reply | 0 comments |
headers
Julian Reschke | 20 Nov 2009 08:08
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
Permalink | Reply | 0 comments |
headers
Cyrus Daboo | 20 Nov 2009 15:11
Favicon

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
Permalink | Reply | 0 comments |
headers
Julian Reschke | 20 Nov 2009 15:13
Picon
Picon

last-calling I-D Action:draft-brown-versioning-link-relations-03

(FYI)

This update to yesterday's draft is purely editorial, moving each link 
relation into a proper subsection, and using the correct IANA 
registration template as defined per RFC 4287.

At this point we'd like to ask the community for final feedback; we are 
planning to request publication in two weeks from now (Dec 04).

Best regards,

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-03.txt
> 	Pages           : 11
> 	Date            : 2009-11-20
> 
> This specification defines Atom link relations for navigation between
> a resource and its versions.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-brown-versioning-link-relations-03.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
(Continue reading)

Permalink | Reply | 31 comments |
headers
Julian Reschke | 20 Nov 2009 15:31
Picon
Picon

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

Cyrus Daboo wrote:
> ...
>> 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.
> ...

<http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.21.1>:

"Creation of identifiers in the "DAV:" namespace is controlled by the IETF."

So it's not relevant whether something is generic. What's important is 
that there's IETF consensus to add new names to the namespace.

I'm not saying this can't be the case here, but I think the proper way 
would be to start with a proposal in a custom namespace, and then switch 
to the DAV: namespace once it's clear that consensus has been achieved.

BR, Julian
Permalink | Reply | 0 comments |

Gmane