Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

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 UTC