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

Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

From: Daniel Brotsky <dbrotsky@adobe.com>
Date: Mon, 25 Feb 2002 13:54:12 -0800
Cc: "Lisa Dusseault" <lisa@xythos.com>, <w3c-dist-auth@w3c.org>
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Message-Id: <340D9C82-2A3A-11D6-8A37-0003931036B4@adobe.com>
I think we're all very interested in the same questions (see my other 
note in this thread).  But I think we need a new issue for it, rather 
than discussing it as part of the lock-null issue.  I think LOCK-based 
resource creation should work just like PUT-based creation does, and the 
spec should simply say that.  This discussion about PUT and GET behavior 
should go with PUT.

     dan

On Monday, February 18, 2002, at 02:03 AM, Stefan Eissing wrote:

>
> Am Sonntag den, 17. Februar 2002, um 04:19, schrieb Lisa Dusseault:
>
>>
>> Stefan Eissing wrote:
>>> Am Freitag den, 15. Februar 2002, um 01:57, schrieb Daniel Brotsky:
>>>
>>>> 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.
>>
>> Application/octet-stream is the generally accepted "don't know what 
>> else to
>> use" MIME type, the default MIME type.  At least if we specify it, 
>> behavior
>> will definitely be consistent.  What's the virtue of not specifying it?
>
> Can we specify answers for all questions below?
>
> 1. When a client creates a resource with "application/octet-stream", 
> should
> the server make a guess and replace octet-stream with another mime type?
>
> 2. When a client creates a resource without mime type, should
> the server make a guess or report application/octet-stream?
>
> 3. When a server reports application/octet-stream, should a client take
> a guess in order to open an application/show an icon?
>
> 4. When a server reports another mime type, is a client allowed to take
> a guess anyway and disregard the server supplied mime type? How does
> a client know that the mime type was not "guessed" by the server?
>
>> I do agree that when a content-type is included in a PUT overwriting 
>> the
>> empty resource, that should become the new content-type.  However 
>> isn't that
>> always the case, whether the resource was previously empty or not?
>
> Yes. The question is more what content-type to report on an empty 
> resource.
>
>> Lisa
>>
>
>
Received on Monday, 25 February 2002 16:53:45 GMT

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