New issue? PUT semantics and MIME header handling

On Thu, May 08, 2003 at 09:57:13AM +0200, Julian Reschke wrote:
> > I agree that it would be great if PUT meant (in practice) "set the state
> > of this resource", as that would allow nice things like a SOAP binding
> > to HTTP which used PUT, as well as just making the method more general.
> > But the bulk of the use of PUT is with DAV, and DAV uses it to mean
> > "store".  Unfortunately, it's problematic to have it mean "store" and
> 
> Well, RFC2518 is silent about that.

Right.  I just meant running code.

> Indeed most uses of WebDAV *currently*
> are basically network filesystems, but there already examples to the
> contrary (for instance, there are servers that do not persist the octet
> stream but the XML infoset of XML entities, thus do not round-trip things
> like whitespace within tags or attribute quotation styles).

Yes, you showed me an example[1] of this before.  Very interesting.

> Maybe the WebDAV WG should consider mechanisms for clients to discover the
> server's expected behaviour, but so far nobody seems to have asked for that
> (in fact, observing the entity tag returned upon PUT may do -- if it's a
> strong etag, the server must have done a "store").

Unfortunately, that's discovered ex post facto.  Mandatory extensions
would seem to be the right answer there.

> > "set" at the same time on the public Web, as there's no way for a PUT
> > message with "set" intent to be distinguished from one with "store"
> > intent, and "set" is incompatible with "store" (as it's more general,
> > not less).  If it were the other way around, and "set" semantics were
> > commonplace, then there would be no issue.  Or, if HTTP had mandatory
> > extensions, then I could use PUT with "set" intent without confusing
> > components that only knew about "store".
> 
> Can you give an example where this kind of confusion arises?

Well, anytime a client does a PUT and expects semantics that a
server doesn't provide.  I understand 2518 is mostly silent on this
issue, but it's my understanding that there exist WebDAV
clients that expect PUT to have store semantics.  Breakage would occur
if they interacted with a server which didn't provide this.

> > enough, so that the cost of changing common practice is less than the
> > value gained from doing so.  I don't know enough about that to say.
> 
> Even if "store" is common practice, IMHO that doesn't mean there's a problem
> with "set".

See previous paragraph.

> > But back to Julian's "Issue #2".  I agree with Roy; a server owner
> > should be allowed to do whatever they want, since the representation
> > crossed a trust boundary.  But on the other hand, there's a cost to
> > changing it, as described above, that needn't exist.  I'd offer this
> > as a TAG issue, but it's rather esoteric.
> 
> On the contrary, I think it's pretty urgent. In authoring scenarios such as
> WebDAV, we can only get clients to properly MIME-label their PUT requests if
> there's some hope that the remote server will care about that.

Good point.  Ok, you've convinced me, this should probably be a new
issue.

> We still
> don't know yet, but this may have been the reason why Apple invented the
> "ical" URI scheme instead of relying on content types, and I think we all
> agree that we want to avoid abuses like that.

Yes.

 [1] darn, I can't find it, but it was on rest-discuss

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis

Received on Thursday, 8 May 2003 14:34:09 UTC