W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2002

Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Fri, 15 Feb 2002 09:40:06 +0100
To: w3c-dist-auth@w3c.org
Message-Id: <9CA625C8-21EF-11D6-8DD2-00039384827E@greenbytes.de>

Am Freitag den, 15. Februar 2002, um 01:57, schrieb Daniel Brotsky:

> On Aug 17 last year, in <http://lists.w3.org/Archives/Public/w3c-dist-
> auth/2001JulSep/0141.html>, Jason closed this issue using the 
> Geoff's language about "act as if a PUT of length 0 happened."
>
> Since I was on vacation at that time, I missed this conclusion, 
> but don't worry: I agree with it!!  (phew :^)  But it raises a 
> question (other than the 201 status response Lisa already raised) 
> and I believe it closes another issue I rasied:
>
> The question: what's the mime-type of the newly-created resource?
>
> Now I know that many servers use file extensions to determine 
> mime-type, so the name of the resource could be used to provide a 
> mime-type.  But for other servers that expect clients to supply a 
> Content-type header on PUT (or at least pay attention to them), 
> what should happen?
>
> My proposal: do not mandate behavior around this; leave the spec 
> silent.  That way the spec is silent about mime-type of LOCK 
> created resources exactly as it's silent about the mime type of 
> PUT resources.

Yesterday we had internally the discussion about the mime-type of
a resource with length 0. I think we did not come to a good conclusion
and the whole mime-type handling is a mess anyway.

The only thing we could agree upon is that a client supplied mime-type
on PUT should be persistet (if possible) and override any name extension
guesswork.


> The issue: LOCK_URL_WITH_NO_PARENT_COLLECTION
>
> In <http://lists.w3.org/Archives/Public/w3c-dist-
> auth/2001JanMar/0134.html> I asked that LOCK return 409 with no 
> body when parent collections don't exist.  There was no discussion 
> (which at the time I took to be assent but the issue was never 
> closed), but with this change in LOCK semantics I believe the 
> issue is forced: LOCK must return 409 (with no body) exactly as 
> PUT does when there are missing parent collections.  So I think 
> this issue should be closed as accepted, unless anyone has a 
> problem with the language I specified in my original message.

Returning 409 sounds reasonable.
Received on Friday, 15 February 2002 03:40:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:59 GMT