- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 29 Dec 2005 09:44:08 +0100
- To: "Roy T. Fielding" <fielding@gbiv.com>
- CC: W3C TAG <www-tag@w3.org>
Roy T. Fielding wrote: > > I don't have any time to take this on, but at some point the TAG > should consider an issue regarding the problems caused by the REPORT > method and its harm to the Web architecture due to > > a) replacing identification of important resources via URIs > with limited indirect access via a related resource: > > <http://www.ietf.org/rfc/rfc3253.txt> section 3.6 > > [should have used a link to a version history resource]. RFC3253 indeed defines a separate version history resource, with its own URI (see <http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.5>); however that one is optional. Most servers I'm aware of indeed support VHR resources, thus clients do not need to use the version-tree report you're complaining about (<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.3.7>). Please don't confuse characteristics of the REPORT method itself (<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.3.6>) with specific reports it is being used for. > b) use as an ad-hoc query-language without consideration for caches: > > <http://www.ietf.org/internet-drafts/draft-dusseault-caldav-09.txt> > > [should be using links to related resources]. Again, that's characteristics of a specific report. I agree with the analysis that this doesn't take caches into consideration, and I have complained about this on the CalDav mailing list. However, this has little to do with REPORT; would the authors have used GET or POST for batching, the problem would have been the same. > c) batching multiple independent requests through a single method: > > > <http://svn.collab.net/repos/svn/trunk/subversion/libsvn_ra_dav/protocol> > > [should be using a client implementation that supported pipelining]. > > I would not be surprised to see SOAP messages carried via REPORT. That would not be compliant to the RFC defining REPORT if execution of the message would affect the state of resources on the server. > The method has no distinguishable semantics from POST aside from > the ability to claim that it isn't just tunneling through POST. Yes, it does: From <http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.3.6>: "The REPORT method MUST NOT have changed the content or dead properties of any resource." Best regards, Julian
Received on Thursday, 29 December 2005 08:52:35 UTC