Julian Reschke wrote:
> ...
>> We still don't have the ability to synchronize property values in
>> WebDAV. We could start designing that, but there's not a strong call
>> to, unless we start getting confused and put data into the metadata.
>
> That's a separate issue that should be solved. As a matter of fact, I
> think I've got a good idea to address this and other related things, but
> I didn't have time so far to write it down (famous last words, I know).
> ...
OK,
in the meantime I've spent some time on a proposal, see
<http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html>.
Essentially it's based on the fact that PROPFIND/REPORT/SEARCH are safe
methods, but that the information they provide is "off" the bookmarkable
and cacheable web. So let's try to fix that.
A new entity header would *allow* the server to advertise that location,
for instance
(<http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html#examples>):
-----
A.1. WebDAV Collection Membership
In this example the client uses the WebDAV PROPFIND method ("HTTP
Extensions for Web Distributed Authoring and Versioning", [RFC4918],
Section 9.1) to get a list of all collection members, along with
their DAV:resourcetype property ([RFC4918], Section 15.9):
>>Request
PROPFIND /collection/ HTTP/1.1
Host: example.com
Depth: 1
Content-Type: application/xml
<propfind xmlns="DAV:">
<prop>
<resourcetype/>
</prop>
</propfind>
The response contains the requested information, plus the GET-
Location header, identifying a separate resource which can provide
the same information using the HTTP GET method:
>>Response
HTTP/1.1 207 Multi-Status
Content-Type: application/xml
GET-Location: <http://example.com/collection/;members>; etag="123";
max-age=3600
<multistatus xmlns="DAV":>
<response>
<href>/collection/</href>
<propstat>
<prop>
<resourcetype><collection/></resourcetype>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<response>
<href>/collection/member</href>
<propstat>
<prop>
<resourcetype/>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
The responses provided the URL of a "gettable" resource, so when the
client wishes to refresh the collection information, it uses that
URI. The response contained the entity tag for the data being
returned, so it can make the request conditional:
>>Request
GET /collection/;members HTTP/1.1
Host: example.com
Accept: application/xml
If-None-Match: "123"
The information did not change, so the server does not need to return
new data:
>>Response
HTTP/1.1 304 Not Modified
Later on, the client tries again. This time, however, a second
member has been added:
>>Request
GET /collection/;members HTTP/1.1
Host: example.com
Accept: application/xml
If-None-Match: "123"
>>Response
HTTP/1.1 200 OK
Content-Type: application/xml
ETag: "124"
<multistatus xmlns="DAV":>
<response>
<href>/collection/</href>
<propstat>
<prop>
<resourcetype><collection/></resourcetype>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<response>
<href>/collection/member</href>
<propstat>
<prop>
<resourcetype/>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<response>
<href>/collection/member2</href>
<propstat>
<prop>
<resourcetype/>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
</multistatus>
Finally, the collection has been removed by somebody else. The
client tries a refresh:
>>Request
GET /collection/;members HTTP/1.1
Host: example.com
Accept: application/xml
If-None-Match: "124"
>>Response
HTTP/1.1 404 Not Found
Note that it may be hard to compute strong entity tags for more
complex PROPFIND responses. For instance, most properties depend on
the state of the collection member, not the state of the collection
itself, and thus the response will change even though the state of
the collection itself did not change.
This is why this extension leaves it to the server whether to return
a GET-Location at all, and if so, whether to return cache validators
along with it.
----
Feedback appreciated,
Julian