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

Re: rfc2518bis Safe Methods vs Redirection issue

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Sat, 18 Sep 2004 22:19:54 -0400
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Jim Luther <luther.j@apple.com>, w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org
Message-ID: <OFB14CC327.BB6190F7-ON85256F14.000CC4FE-85256F14.000CCF44@us.ibm.com>
That would be fine with me.

Cheers,
Geoff

Julian wrote on 09/18/2004 03:17:51 PM:

> 
> 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 Sunday, 19 September 2004 02:20:52 GMT

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