RFC Errata
Found 9 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)
Status: Held for Document Update (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: 1207
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2008-01-03
Held for Document Update by: Peter Saint-Andre
Section 9.10.1 says:
A LOCK request to an existing resource will create a lock on the resource identified by the Request-URI, provided the resource is not already locked with a conflicting lock. The resource identified in the Request-URI becomes the root of the lock. LOCK method requests to create a new lock MUST have an XML request body. The server MUST preserve the information provided by the client in the 'owner' element in the LOCK request. The LOCK request MAY have a Timeout header.
It should say:
A LOCK request to an existing resource will create a lock on the resource identified by the Request-URI, provided the resource is not already locked with a conflicting lock. The Request-URI becomes the root of the lock. LOCK method requests to create a new lock MUST have an XML request body. The server MUST preserve the information provided by the client in the 'owner' element in the LOCK request. The LOCK request MAY have a Timeout header.
Notes:
This is incorrect in that it implies that the "lock root" is a resource, not a URL (<http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=251>). However, should a directly locked resource have multiple bindings, only the one used in the Request-URI of the LOCK request will be the protected from changes of clients not supplying the lock token.
Note that this change makes the description consistent with the definition of the DAV:lockroot XML element in Section 14.12 of [RFC4918].
Errata ID: 1371
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2008-03-14
Held for Document Update by: Peter Saint-Andre
Date Held: 2010-07-07
Section 9.2 says:
Servers MUST process PROPPATCH instructions in document order (an
exception to the normal rule that ordering is irrelevant).
It should say:
Servers MUST process the child elements of the propertyupdate XML
element in the order they appear in the request body (an exception to
the normal rule that ordering is irrelevant).
Notes:
There are no "PROPPATCH" instructions in the request document (PROPPATCH is a method name, not an XML element name used in WebDAV).
Note this issue was raised during Gen-art review, but not fixed before publication (http://www.ietf.org/mail-archive/web/gen-art/current/msg01823.html)
Errata ID: 1635
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Zdenek Kouba
Date Reported: 2008-12-13
Held for Document Update by: Alexey Melnikov
Date Held: 2010-07-11
Section 7.4 says:
MOVE an internal member into the collection,
It should say:
MOVE inserting a new internal member into the collection,
Notes:
Edited the corrected text as per discussion between Lisa and Julian.