On May 22, 2017, at 11:59 AM, Ken Murchison
<murch(_at_)andrew(_dot_)cmu(_dot_)edu> wrote:
On 05/17/2017 09:58 AM, Julian Reschke wrote:
On 2017-05-17 15:07, Ken Murchison wrote:
...
Only for creation of the attachment. Once is has been created, it
should have its own URI, and the usual HTTP methods should be applicable.
Using HTTP methods directly on the attachment URI makes things more
difficult because the calendar resource(s) referencing the attachment
also need to be updated. This would have to be done either as a
side-effect of the PUT/DELETE on the attachment, or as a separate PUT
(and separate round-trips) on the resource(s). The desire was to avoid
doing either one of these, which is why a POST on the calendar resource
was chosen as the method to add/update/delete an attachment from a
calendar resource.
But the POST is *not* on the calendar resource, but on the calendar resource
+ query parameters, which, from HTTP's point of view is a different resource
already.
Furthermore, what URIs are used is orthogonal to the question of which
methods to use.
Why is
POST /calendar-entry?action=remove&attachment=xyz
easier to process than
DELETE /calendar-entry?attachment=xyz
or
DELETE /calendar-entry/attachments/xyz
?
The issue here is that a single calendar resource may contain multiple events
(recurring event with overrides) and a particular attachment may be
associated with more than one instance of that event. For this reason, we
felt it best to use the calendar resource as the gateway to the attachments,
thus allowing manipulating multiple instances of an attachment in a single
round-trip. Also, by preventing clients from manipulating attachments
directly, a CalDAV server isn't forced to alter all calendar resources
associated with a particular attachment.
But that isn't relevant to the choices here. HTTP is not a filesystem.
A single implementation (e.g., caldav resource) can handle a wide variety
of URLs (identified HTTP resources) with all sorts of co-dependencies in
the state represented by those resources. They are all part of the calendar.
The method states the kind of action being made.
Likewise, an identifier for the attachment associated with the calendar entry
doesn't have to be the same as the identifiers for interacting with the
attachment directly. For example, the calendar might provide one identifier
for the original attachment, a second for the attachment currently applicable
to a given instance of an entry, and a third for updating future instances
of that repeating event (i.e., all defined by the server, not the protocol).
In any case, one of the cornerstones of caldav practice is that caldav
provides just one interface to an abstract Calendar database normally
accessed via many different protocols/systems. The Calendar should already
be maintaining coherence between entries and attachments, just like it
shouldn't require a new entry be created every time the invitation list
is expanded.
We also have a fairly large number of deployed implementations which we do
not want to make non-compliant by substantially modifying the protocol. At
this point, specifying the use of HTTP methods other than POST would indeed
make existing implementations non-compliant.
Specifying method actions within URL query strings is well-known to be
bad practice. However, if you are okay with specifying an IETF protocol
that contains obviously bad practice in its application of HTTP,
a minimum would be to reference section 4.2.1 of RFC7231, where it states:
When a resource is constructed such that parameters within the
effective request URI have the effect of selecting an action,
it is the resource owner's responsibility to ensure that the action
is consistent with the request method semantics. For example, it is
common for Web-based content editing software to use actions within
query parameters, such as "page?do=delete". If the purpose of such a
resource is to perform an unsafe action, then the resource owner MUST
disable or disallow that action when it is accessed using a safe
request method. Failure to do so will result in unfortunate side
effects when automated processes perform a GET on every URI reference
for the sake of link maintenance, pre-fetching, building a search index, etc.
We would definitely like to make this protocol conform to current HTTP
practice where possible, and would also document where we have strayed from
existing practice if required to do so. Do you think we can come to some
kind of consensus that meets these goals?
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
I honestly don't see how this can be considered an extension of WebDAV
and yet have such a profound misunderstanding of method semantics.
Other applications of HTTP might be expected to work around PUT/DELETE,
but not a WebDAV server.
Likewise, defining a protocol in terms of predefined URL patterns and
specific query components is fundamentally incompatible with REST.
OTOH, it's not the first time this has come up. HTTP provides plenty
of rope, for good reasons, and these types of choices seem only to
harm those using the rope. Maybe a future version will just use HTTP.
Cheers,
Roy T. Fielding <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe <https://www.adobe.com/>