W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2004

Re: rfc2518bis Safe Methods vs Redirection issue

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 20 Sep 2004 10:04:13 -0700
Message-Id: <1935B2AB-0B27-11D9-BF97-000A95B2BB72@osafoundation.org>
Cc: w3c-dist-auth@w3.org, Jim Luther <luther.j@apple.com>
To: Julian Reschke <julian.reschke@gmx.de>

I agree -- they all should be unsafe but idempotent.

Lisa

On Sep 18, 2004, at 12:17 PM, Julian Reschke wrote:

>
> Jim Luther wrote:
>> In the HTTP/1.1 Specification Errata 
>> <http://purl.org/NET/http-errata> there is a section titled "Safe 
>> Methods vs Redirection" which concludes with "It would also be 
>> helpful for each of the method definition sections to specifically 
>> define whether or not the method is safe. OPTIONS, GET, and HEAD are 
>> all safe in RFC 2616. HTTP extensions like WebDAV define additional 
>> safe methods."
>> I don't see anywhere in rfc2518 or rfc2518bis where WebDAV methods 
>> are defined as safe or unsafe. rfc2518bis should probably state which 
>> WebDAV methods are safe and which are unsafe.
>> In my code, I'm assuming PROPFIND is a safe method and that 
>> PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK are unsafe methods by 
>> the definitions in rfc2616, section 9.1.1 "Safe Methods". Does that 
>> sound right to the working group?
>
> So should we state this in the BIND spec? Such as:
>
> BIND
>
> This method is unsafe and idempotent (see RFC2616, section 9.1).
>
> REBIND
>
> This method is unsafe and idempotent (see RFC2616, section 9.1).
>
> UNBIND
>
> This method is unsafe and idempotent (see RFC2616, section 9.1).
>
>
> Feedback appreciated,
>
> Julian
>
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
Received on Monday, 20 September 2004 17:04:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:06 GMT