Showing content from https://greenbytes.de/tech/webdav/draft-reschke-webdav-allprop-include-02.xml below:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . Recent specifications extending the "Web Distributed Authoring Protocol" (WebDAV, ) like "Versioning Extensions to WebDAV" and "WebDAV Access Control Protocol" restrict the set of properties returned automatically upon a PROPFIND/allprop request in order to avoid the expensive computation of properties that the client in many cases isn't interested in. However, this change from the behaviour defined in WebDAV can lead to situations where clients need to perform two requests to retrieve all properties they are interested in (one using PROPFIND/allprop, then PROPFIND/prop enumerating the new properties that weren't reported upon the first request). This specification defines a backward-compatible extension to add specific properties to the set of properties returned upon PROPFIND/allprop, thus saving at least one PROPFIND request. This document defines an extension element that could ultimately become part of the core WebDAV protocol. Being just an individual submission, it currently defines it in the proprietary namespace http://sapportals.com/xmlns/cm/webdav instead of the "DAV:" namespace. It uses a prefix of "in:" for referring to elements in this namespace. However, WebDAV server and clients are free to use any prefix, provided that there is a namespace declaration that binds the prefix to the URI of the same namespace. The "allprop" version of PROPFIND is extended to take an optional <in:include> element. When present, it contains a set of property names that shall be reported in addition to those properties that the server usually would return upon PROPFIND/allprop. >>Request PROPFIND /container/front.html HTTP/1.1 Host: www.foo.bar Depth: 1 Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <propfind xmlns="DAV:" xmlns:in="http://sapportals.com/xmlns/cm/webdav"> <allprop/> <in:include> <checked-in/> <checked-out/> </in:include> </propfind> >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <multistatus xmlns="DAV:"> <response> <href>http://www.foo.bar/container/front.html<href> <propstat> <prop> <R:bigbox xmlns:R="http://www.foo.bar/boxschema/"> <R:BoxType>Box type B</R:BoxType> </R:bigbox> <creationdate>1997-12-01T18:27:21-08:00</creationdate> <displayname>Example HTML resource</displayname> <getcontentlength>4525</getcontentlength> <getcontenttype>text/html</getcontenttype> <getetag>zzyzx</getetag> <getlastmodified >Monday, 12-Jan-98 09:25:56 GMT</getlastmodified> <resourcetype/> <supportedlock> <lockentry> <lockscope><exclusive/></lockscope> <locktype><write/></locktype> </lockentry> <lockentry> <lockscope><shared/></lockscope> <locktype><write/></locktype> </lockentry> </supportedlock> <checked-in> <href >http://www.foo.bar/versions/container/front.html-1</href> </checked-in> </prop> <status>HTTP/1.1 200 OK</status> </propstat> <propstat> <prop> <checked-out/> </prop> <status>HTTP/1.1 404 NOT FOUND</status> </propstat> </response> </multistatus> In this example, the server has recognized the extension element <in:include> and included the DAV: properties <checked-in> and <checked-out> (as defined in ). >>Request PROPFIND /container/front.html HTTP/1.1 Host: www.foo.bar Depth: 1 Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <propfind xmlns="DAV:" xmlns:in="http://sapportals.com/xmlns/cm/webdav"> <allprop/> <in:include> <checked-in/> <checked-out/> </in:include> </propfind> >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <multistatus xmlns="DAV:"> <response> <href>http://www.foo.bar/container/front.html<href> <propstat> <prop> <R:bigbox xmlns:R="http://www.foo.bar/boxschema/"> <R:BoxType>Box type B</R:BoxType> </R:bigbox> <creationdate>1997-12-01T18:27:21-08:00</creationdate> <displayname>Example HTML resource</displayname> <getcontentlength>4525</getcontentlength> <getcontenttype>text/html</getcontenttype> <getetag>zzyzx</getetag> <getlastmodified >Monday, 12-Jan-98 09:25:56 GMT</getlastmodified> <resourcetype/> <supportedlock> <lockentry> <lockscope><exclusive/></lockscope> <locktype><write/></locktype> </lockentry> <lockentry> <lockscope><shared/></lockscope> <locktype><write/></locktype> </lockentry> </supportedlock> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> In this case the <in:include> element was simply ignored. The client can detect this situation by checking for the presence of the requested properties and will have to issue an additional PROPFIND/prop request (to retrieve the missing properties). <!ELEMENT propfind ((allprop, in:include+) | propname | prop) > <!ELEMENT in:include ANY > Note that the WebDAV DTD is informal only and cannot be used to validate request or response bodies (due to the inability to properly work with XML namespaces). This specification introduces a new child element for the <propfind> element, defined in . Old servers will ignore this element (see , chapter 14). Clients can detect this situation as outlined in . Clients not aware of this specification will not be affected at all, because they will never use the new <in:include> element in PROPFIND requests. This proposal builds on , and inherits its internationalizability. This proposal does not introduce any new IANA considerations, since it does not specify any new namespaces (in the general sense), but merely uses existing ones. To be supplied by the RFC Editor. To be supplied by the RFC Editor.
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4