[Bug 112] MKCOL_AND_302

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=112





------- Additional Comments From julian.reschke@greenbytes.de  2005-12-12 12:38 -------
> The rationale for explicitly stating that 3xx redirects apply is as follows.
> 
> Most use of HTTP is for reading resources. For reads, it's pretty clear what a
redirect means -- go 
> someplace else and read what's there.
> 
> If you have been strongly conditioned to view redirects as just applying to
reads, then having redirects 
> apply to writes seems a bit strange. Most people have *never* worked with a
system that can possibly 
> store your data under a different location than the one you initially
specified. For example, file systems 
> do not work this way. As a result, even though it is a straightforward
extension of the semantics of the 
> 3xx responses, it still runs counter to the predominant set of experiences
that most programmers have. 
> It also seems potentially dangerous -- what if my work is written someplace I
don't want it to go?

Then your user agent is broken. HTTP is very clear about the fact that clients
must not automatically follow redirects upon invocations of unsafe methods (see
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.10.3> and
<http://skrb.org/ietf/http_errata.html#saferedirect>).

> Since this behavior is non-typical (as compared to the "typical" filesystem
behavior), it makes sense for 
> all write operations to explicitly state that they can be redirected via 3xx.
The reason we don't 
> exhaustively list that all HTTP responses potentially apply to all WebDAV
methods is because most 
> HTTP response codes don't involve semantics that run counter to the typical
experience of developers. 
> That is, 3xx is exceptional, exactly because the semantics are atypical.

So again, why not state it for LOCK, PUT, PROPPATCH then? Still not convinced.




------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

Received on Monday, 12 December 2005 20:38:26 UTC