errata logo graphic

Found 6 records.

Status: Verified (3)

RFC4918, "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", June 2007

Source of RFC: webdav (app)

Errata ID: 1068

Status: Verified
Type: Technical

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

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

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: Held for Document Update (3)

RFC4918, "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", June 2007

Source of RFC: webdav (app)

Errata ID: 1207

Status: Held for Document Update
Type: Technical

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

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

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