RFC Errata
Found 6 records.
Status: Verified (3)
RFC 4918, "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", June 2007
Note: This RFC has been updated by RFC 5689
Source of RFC: webdav (app)
Errata ID: 1068
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2007-11-13
Verifier Name: Lisa Dusseault
Date Verified: 2007-11-13
Section 10.4.7 says:
If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
<urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>)
It should say:
If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>
<urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>)
Notes:
Indentation is relevant here. In the published form, the second line would be a separate (invalid) HTTP header, not a continuation line.
Errata ID: 1519
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Manfred Baedke
Date Reported: 2008-09-19
Verifier Name: Peter Saint-Andre
Date Verified: 2011-06-08
Section 8.3 says:
Within Simple-ref productions, senders MUST NOT:
o use dot-segments ("." or ".."), or
o have prefixes that do not match the Request-URI (using the
comparison rules defined in Section 3.2.3 of [RFC2616]).
It should say:
Within Simple-ref productions, senders MUST NOT use dot-segments ("." or "..").
Simple-ref productions used in Multi-Status responses MUST NOT have prefixes that
do not match the Request-URI (using the comparison rules defined in Section 3.2.3
of [RFC2616]).
Notes:
The original text explicitly applies not only to Simple-ref productions used in Multi-Status responses, but also to those used in Destination Headers. Since URIs used in Destination headers may have other prefixes (for example in a cross-server COPY request), this is wrong.
Errata ID: 1430
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Werner Baumann
Date Reported: 2008-05-26
Verifier Name: Lisa Dusseault
Date Verified: 2008-05-30
Section 9.3 says:
9.3. MKCOL Method MKCOL creates a new collection resource at the location specified by the Request-URI. [...]
It should say:
9.3 MKCOL Method The MKCOL method is used to create a new collection. All DAV compliant resources MUST support the MKCOL method. MKCOL creates a new collection resource at the location specified by the Request-URI. [...]
Notes:
The statement, that support for MKCOL is a MUST-requirement has unintentionally been dropped.
Status: Reported (3)
RFC 4918, "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", June 2007
Note: This RFC has been updated by RFC 5689
Source of RFC: webdav (app)
Errata ID: 4431
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Worik Stanton
Date Reported: 2015-08-02
Throughout the document, when it says:
Notes:
The phrase: "live properties defined in this specification." is used throughout RFC4918 but there is no place they are defined.
Careful reading can deduce what they may be, but that is not satisfactory. It would be better to actually define them.
Errata ID: 4435
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Worik Stanton
Date Reported: 2015-08-05
Section 9.8.5 says:
It should say:
The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is temporary or permanent; the 410 (Gone) status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition is likely to be permanent.
Notes:
The case of the resource being copied not existing is not covered. I assume that a 404 error is appropriate, but that is my assumption.
Errata ID: 4440
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Worik Stanton
Date Reported: 2015-08-09
Section 9.8 says:
Notes:
There are several ambiguities in this section. Here is one.
Copying a resource to a defined collection:
From To Result
/a/c/d /b/ /b/d
This is the logical interpretation and does not conflict with the specifications. But...
From To Result
/a/c/d /b/ /d (/b/ is overwritten)
This perverse but does not conflict either. Trashing he complete collection in this way cannot be right, but it is not in conflict with anything I can find in section 9.8. The closest I can find is:
"When a collection is overwritten, the membership of the destination collection after the successful COPY request MUST be the same membership as the source collection immediately before the COPY."
This does not explicitly prohibit overwriting a collection with a non-collection.
The specification uses "in the destination.." and "at the destination..." interchangeably.
"The COPY method creates a duplicate of the source resource identified by the Request-URI, in the destination resource identified by the URI in the Destination header." This suggests the first
The specification also says: "When the source resource is not a collection, the result of the COPY method is the creation of a new resource at the destination whose state and behavior match that of the source resource as closely as possible." This could mean the second.
Possibly copying a non-collection resource to a collection resource should not be allowed (but I can find no such prohibition)