[Bug 100] "Notes on HTTP Client Compatibility" useful?

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

julian.reschke@greenbytes.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |
            Version|-10                         |-13



------- Additional Comments From julian.reschke@greenbytes.de  2006-02-15 06:23 -------
Current text
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-13.html#rfc.section.B>:

-- start --

B. Notes on HTTP Client Compatibility

WebDAV was designed to be, and has been found to be, backward-compatible with
HTTP 1.1. The PUT and DELETE methods are defined in HTTP and thus may be used by
HTTP clients as well as WebDAV-aware clients, but the responses to PUT and
DELETE have been extended in this specification in ways that only a WebDAV
client would be entirely prepared for. Some theoretical concerns were raised
about whether those responses would cause interoperability problems with
HTTP-only clients, and this section addresses those concerns.

Since any HTTP client ought to handle unrecognized 400-level and 500-level
status codes as errors, the following new status codes should not present any
issues: 422, 423 and 507 (424 is also a new status code but it appears only in
the body of a Multistatus response.) So, for example, if a HTTP client attempted
to PUT or DELETE a locked resource, the 423 Locked response ought to result in a
generic error presented to the user.

The 207 Multistatus response is interesting because a HTTP client issuing a
DELETE request to a collection might interpret a 207 response as a success, even
though it does not realize the resource is a collection and cannot understand
that the DELETE operation might have been a complete or partial failure. Thus, a
server MAY choose to treat a DELETE of a collection as an atomic operation, and
use either 204 No Content in case of success, or some appropriate error response
(400 or 500 level) depending on what the error was. This approach would maximize
backward compatibility. However, since interoperability tests and working group
discussions have not turned up any instances of HTTP clients issuing a DELETE
request against a WebDAV collection, this concern may be more theoretical than
practical. Thus, servers MAY instead choose to treat any such DELETE request as
a WebDAV request, and send a 207 Multistatus containing more detail about what
resources could not be deleted.

In general server implementations are encouraged to use the detailed responses
defined in this document and to avoid attempts to detect client version or to
determine client compatibility.

-- end --

Comment: Again, the idea that a server changes handling of a request based on
what it thinks the type of client makes me shudder. Any mention of this really
needs to go. Futhermore, this section should clarify that HTTP defines a 2xx
code as: "This class of status code indicates that the client's request was
successfully received, understood, and accepted." So any claim that 2xx
indicates successful *execution* of a method is incorrect anyway.



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

Received on Wednesday, 15 February 2006 14:23:47 UTC