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

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

           Summary: "Notes on HTTP Client Compatibility" useful?
           Product: WebDAV-RFC2518-bis
           Version: -07
          Platform: Other
               URL: http://greenbytes.de/tech/webdav/draft-ietf-webdav-
                    rfc2518bis-07.html#rfc.section.B.2
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Appendix B.  Appendices
        AssignedTo: joe-bugzilla@cursive.net
        ReportedBy: julian.reschke@greenbytes.de
         QAContact: w3c-dist-auth@w3.org


This section is completely new, and I do not remember any prior discussion. Why
was it added? What problem does it solve?

In particular:

"First, if a PUT or DELETE request includes a header defined in this
specification (Depth or If), the server can assume the request comes from a
WebDAV-compatible client. The server may even be able to track a number of
requests across a session and know that a client is a WebDAV client. However,
this kind of detection may not be necessary."

What is this about? Why would a server care? Why *should* a server care?

"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. ..."

Yes. This spec uses new response codes; as do others. I'm not sure why we need
to talk about this, unless it solves a specific problem I'm currently not aware of.

"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."

That would contradict Section 9.2 (Delete,
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-07.html#rfc.section.9.2.p.7>):

"Upon execution, a method with a Depth header will perform as much of its
assigned task as possible and then return a response specifying what it was able
to accomplish and what it failed to do."

Do we want to change that requirement for DELETE?

"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."

Yes.

"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."

The notion of a DELETE request sometimes beings a "WebDAV" request and sometimes
not is a completely new concept; and I think it's a bad idea as well. The same
HTTP message must mean the same thing, independantly of who is sending it (and
what it did before).



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

Received on Wednesday, 12 October 2005 06:35:20 UTC