Subject: XML in LOCK <owner> tag should be self-contained

From: "John Spaith" <[email-masked]>
Date: Fri, 20 Sep 2002 08:56:51 -0700

Ladies and Gentleman,
 
At the WebDAV interop fest, we saw that some servers weren't doing the
right thing when clients send them <owner> tags on a LOCK request.  When
doing a LOCK a client can put in XML in the owner tag, and this XML
often times has namespaces prefixes in it.  So we have something like...

LOCK
 
<xml>
 <lockinfo xmlns:MyNS="MyNameSpace">
  [...]
   <owner>
      <MyNS:MyTag>...</MyNS:MyTag>
   </owner>
  [...]
 
When the server returns this owner tag on a lockdiscovery, it has to
also return the definition of the MyNS namespace in the <owner> tags or
clients will choke on not recognizing MyNS prefix.  Having to keep track
of prefix mappings when parsing the LOCK body is an added piece of
complexity that servers don't really need.  It would be better if we
could require (or more likely strongly encourage) clients to make any
XML inside the <owner> tag work standalone, i.e. forcing them to define
any namespaces they use there.  They would send something like this on a
LOCK.
 
 <owner>
   <MyNS:MyTag xmlns:MyNS="MyNameSpace">...</MyNS:MyTag>
 </owner>
 
This way the server could just keep a copy of the data between the
<owner> tags without any extra processing.
 
Steps to increase interop:
1. Server implementers should be aware of this and code accordingly.  A
number of servers at the WebDAV interop fest only copied the data
between <owner> tags, not doing the extra name space processing.
 
2. We should say something to the effect that clients SHOULD send
self-contained XML data with all the namespaces prefixes they used
defined between the <owner> tags to workaround servers that don't handle
this correctly.
 
3. We should practice what we preach in the spec.  For instance in RFC
2518 example 8.10.8, we have <D:href> inside an <owner> tag that could
cause certain servers to have the problem described here.
 
4. We should keep general scenario in mind when writing specs in the
future that involve one party saving XML with namespace tags in it from
another party, possibly saying that the client MUST send self-contained
XML.
 
Alas, since RFC 2518 is a done-deal there's not much we can do on #3.
Issues #1 and #2 are mostly education issues for WebDAV client and
server implementers.  The main reason I'm writing this is for #4, so
that we can be aware of this scenario in the future.
 
Thank you,
John Spaith
Software Design Engineer
Windows CE
Microsoft

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 20 Sep 2002 19:01:32 +0200

1) References to RFC2616

References have been updated to point to RFC2616 rather than RFC2068, but it
seems that all (most?) section numbers still need to be updated.

2) Section 4.4

Replace "MUST not" by "MUST NOT"

3) Section 4.6

I think this section needs to be deleted (it refers to the source link
stuff)

4) Section 6.3, p1

Replace

"A lock token is returned by every successful LOCK operation in the
lockdiscovery property in the response body, and can also be found through
lock discovery on a resource."

by

"A lock token is returned by every successful LOCK operation in the
lock-token header of the response, and can also be found through lock
discovery on a resource"

5) Section 6.3, p3

Replace

"However resources are free to return any URI scheme so long as it meets the
uniqueness requirements."

by

"However servers are free to use any IETF-registered URI scheme so long as
it meets the uniqueness requirements."

6) Section 8.1, p1 (use of XML)

Replace

"Some of the following new HTTP methods use XML as a request and response
format.  All DAV compliant clients and resources MUST use   XML parsers that
are compliant with [REC-XML].  All XML used in either requests or responses
MUST be, at minimum, well formed.  If a server receives ill-formed XML in a
request it MUST reject the entire request with a 400 (Bad Request)."

by

"Some of the following new HTTP methods use XML as a request and response
format.  All DAV compliant clients and resources MUST use   XML parsers that
are compliant with [REC-XML] and [REC-XML-NAMES].  All XML used in either
requests or responses MUST be, at minimum, well formed and
namespace-well-formed.  If a server receives ill-formed XML in a request it
MUST reject the entire request with a 400 (Bad Request)."

7) Section 8.1, p2 (required bodies)

says...: "In cases where a request body is present but would be ignored by a
server, the server MUST reject the request with 415 (Unsupported Media
Type)."

I don't understand this requirement. If a body isn't defined, it should be
ignored, right?

8) Section 8.1, p3 (required headers)

"Note that HTTP 1.1 requires the Date header in all responses." -> not
true - clockless origin servers are treated as a special case

"WebDAV servers MUST support ETags correctly and MUST return the ETag header
in all GET and PUT responses. " -> strong disagreement (see separate thread
on the mailing list)

9) Section 8.2

"URLs for collections appearing in the results MUST end in a '/'
character." -> I don't think we have consensus on this.

Furthermore, this section seems to attempt to define a subset of relative
URI resolution -- I think this is a VERY bad idea. Clients should properly
resolve URIs against the request URI -- if we must, we can simplify this
requirement by restricting the set of allowed relative URIs to those
starting with an absolute path.

10) Section 8.2.2

"The resource http://www.foo.bar/container/index.html, a member of the
"container" collection, has nine properties defined on it,
http://www.foo.bar/boxschema/bigbox, DAV:creationdate, DAV:displayname,
DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, DAV:getlastmodified,
DAV:resourcetype, and DAV:supportedlock." -> bad syntax for property names.

Also: the example for propfind/allprop is missing.

11) Section 8.3

"All DAV compliant resources MUST support the PROPPATCH method and MUST
process instructions that are specified using the propertyupdate, set, and
remove XML elements of the DAV schema" -> What is the "DAV schema"???

Also, replace

"Instruction processing MUST occur in the order instructions are received
(i.e., from top to bottom)"

by

"Instruction processing MUST occur in document order" (standard XML
processing term)

12) Section 8.7

Replace

"If an error occurs with a resource other than the resource identified in
the Request-URI then the response MUST be a 207 (Multi-Status), and the
errored resourceAs URL MUST appear with the specific error."

by

"If an error occurs with a resource other than the resource identified in
the Request-URI then the response MUST be a 207 (Multi-Status), and the URL
of the resource causing the failure MUST appear with the specific error."

(similar wording appears several times in later sections)

Also, replace

"424 (Failed Dependency) errors SHOULD NOT be in the 207 (Multi-Status)."

by

"424 (Failed Dependency) errors SHOULD NOT appear in the 207
(Multi-Status)."

13) Section 8.11, refreshing locks

"A locks is refreshed by sending a new LOCK request to the resource which is
the root of the lock."

Question: does it really need to be the root?

14)  Section 8.11, The Effect of Locks on Properties and Collections

"This means that if a collection is locked, its lock-token is required in
all these cases:
-	DELETE a collection's direct  internal member
-	MOVE a member out of the collection
-	MOVE a member into the collection, unless it overwrites a pre-existing
member"

I think the latter is not really consistent with RFC3253.

15) Section 8.11, Locking unmapped URLs

"A server MUST respond successfully to a GET request to an empty resource,
either by using a 204 No Content response, or by using 200 OK with a
Content-Length header indicating zero length and an server-determined
Content-Type."

Do not mention the content type at all. No content type is fine as well.

16) Section 8.11.2

Replace

"Lock-Token: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)"

by

"Lock-Token: <opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>"

17) Section 8.12

Replace

"A successful response to an UNLOCK method does not mean that the resource
is unlocked."

by

"A successful response to an UNLOCK method does not mean that there are no
locks left on the resource."

(at least I think this is the intent of the sentence, otherwise it needs to
be rephrased differently)

18) Section 9.1

I'd like to see the rational for the "extend" production.

19) Section 9.3

Language describing the process of relative URI resolution should go.

20) Section 9.4

See mailing list thread.

21) Section 11.4

Replace

" - The server does not ever accept this method on this kind of resource.
For example, a PUT is not accepted on a collection."

by

" - The server does not ever accept this method on this kind of resource.
For example, if a PUT is not accepted on a collection."

22) Section 11.5

I think that there are *many* more cases that can cause a 409 (see RFC3253)

23) Section 12

Again, an attempt to define relative URI resolution. Don't do that, just
refer to RFC2396 and say that URIs in a multistatus response are resolved
against the request URI.

24) Section 12.1

Proposal: add an example.

25) Section 13.4 (lockroot)

Proposal: only require it for deep locks.

26) Section 13.6

Replace:

"Identifies the associated resource as a collection. The resourcetype
property of a collection resource MUST have this value"

by

"Identifies the associated resource as a collection. The resourcetype
property of a collection resource MUST contain this element."

27) Section 13.16

Remove

"May contain additional elements not defined in this document."

That's true for *all* XML in request/response bodies (also reccurs in other
places)

28)  Section 13.24

Replace

"Language tagging information in the property's value (in the "xml:lang"
attribute, if present MUST be persistently stored along with the property,
and MUST be subsequently retrievable using PROPFIND."

by

"Language tagging information in scope of the property (in the "xml:lang"
attribute, if present MUST be persistently stored along with the property,
and MUST be subsequently retrievable using PROPFIND."

29) Section 13.26

Replace

"The allprop XML element specifies that all property names  and values on
the resource are to be returned."

by

"The allprop XML element specifies that all names and values of all dead
properties and the live properties defined by this document on the resource
are to be returned."

30) Section 14.7

"A change in a property SHOULD NOT cause the last-modified date to change,
because clients MAY rely on the last-modified date to know when to overwrite
the existing body."

I think this is a new requirement that hasn't been discussed. BTW: it's
inconsistent with the attempt to make ETags a MUST -- if you have Etags, you
don't have to rely on the last modified date anyway.

31) Section 18.6, Reduction of Security due to Source Link

can be removed

32) Section 19, IANA consideration (old text)

"URIs are used for both names, for several reasons. Assignment of a URI does
not require a request to a central naming authority, and hence allow WebDAV
property names and XML elements to be quickly defined by any WebDAV user or
application.  URIs also provide a unique address space, ensuring that the
distributed users of WebDAV will not have collisions among the property
names and XML elements they create"

This is wrong. Properties are NOT identified by URIs. They are identified by
XML QNames.

33) Editorial note

I think that removing the section numbers from the 3rd-level section names
is a bad idea.

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 20 Sep 2002 19:12:21 +0200

MessageI think this is identical to the problem of how faithfully the
namespace prefixes are preserved inside dead properties.

IMHO

- namespace information must be preserved (hopefully this is obvious)
- namespace prefixes on elements *inside* prooerty values should be
preserved
- namespace declarations that are needed but appeared outside the actual
property may be returned anywhere recreating the correct scope

This should then also apply the content of the DAV:owner element.

Julian

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of John Spaith
  Sent: Friday, September 20, 2002 5:57 PM
  To: [email-masked]
  Subject: XML in LOCK <owner> tag should be self-contained

  Ladies and Gentleman,

  At the WebDAV interop fest, we saw that some servers weren't doing the
right thing when clients send them <owner> tags on a LOCK request.  When
doing a LOCK a client can put in XML in the owner tag, and this XML often
times has namespaces prefixes in it.  So we have something like...

  LOCK

  <xml>

  When the server returns this owner tag on a lockdiscovery, it has to also
return the definition of the MyNS namespace in the <owner> tags or clients
will choke on not recognizing MyNS prefix.  Having to keep track of prefix
mappings when parsing the LOCK body is an added piece of complexity that
servers don't really need.  It would be better if we could require (or more
likely strongly encourage) clients to make any XML inside the <owner> tag
work standalone, i.e. forcing them to define any namespaces they use there.
They would send something like this on a LOCK.

   <owner>

  This way the server could just keep a copy of the data between the <owner>
tags without any extra processing.

  Steps to increase interop:
  1. Server implementers should be aware of this and code accordingly.  A
number of servers at the WebDAV interop fest only copied the data between
<owner> tags, not doing the extra name space processing.

  2. We should say something to the effect that clients SHOULD send
self-contained XML data with all the namespaces prefixes they used defined
between the <owner> tags to workaround servers that don't handle this
correctly.

  3. We should practice what we preach in the spec.  For instance in RFC
2518 example 8.10.8, we have <D:href> inside an <owner> tag that could cause
certain servers to have the problem described here.

  4. We should keep general scenario in mind when writing specs in the
future that involve one party saving XML with namespace tags in it from
another party, possibly saying that the client MUST send self-contained XML.

  Alas, since RFC 2518 is a done-deal there's not much we can do on #3.
Issues #1 and #2 are mostly education issues for WebDAV client and server
implementers.  The main reason I'm writing this is for #4, so that we can be
aware of this scenario in the future.

  Thank you,
  John Spaith
  Software Design Engineer
  Windows CE
  Microsoft