RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata



Advanced Search