RE: Proposal for encoding a resource with properties

So, I've read through this proposal, and while I like its goals, I disagree
with its mechanisms.

It seems to me to be a bad idea to submit a resource by reference, since it
requires the server to receive the reference, then go and perform another
network request to try and get the value of the resource.  The server could
not then give a status response to the first request until it had finished
dereferencing the reference.  Also, the assumption is that the request would
be a GET witohut accept headers.  But what if someone subsequently did want
to use accept headers.  This adds extra marshalling complexity.

Furthermore, this could be used for some subtle attacks, for example
submitting a URL to an infinitely large resource, trying to fill the
server's storage, or by submitting a lot of requests, and hence effecting a
denial of service attack.

Beyond the problems with passing a reference, there is the issue of encoding
arbitrary binary information inside an XML element, which is difficult to do
in XML.  Even in CDATA sections you need to watch out for the escape
sequence and encode around it if it occurs naturally.

As a result, I think the best way to encode a resource in a MIME message is
to put the body in one MIME chunk, and the properties in another chunk, and
send it together as an appropriate multipart/ type.  Since one of the goals
is to support submission of a bunch of resources together in a MKCOL body,
this could be done by sending a series of nested multiparts, each top level
multipart containing one internal multipart, containing two parts, one for
the resource, one for properties.

The memo only discusses using this encoding with MKCOL, but it seems that it
would be quite useful to use it on individual, existing resources.  Perhaps
a RPUT method should be defined, which only will write if the resource is
locked, and which will write the body and the properties in one atomic
operation.  I can see this being useful to a number of clients.

- Jim

Received on Tuesday, 9 March 1999 18:55:27 UTC