Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

Ah, but there's a real subtlety here.  2616 only gives rules regarding 
the determination of the MESSAGE's entity body type; it says nothing 
about what (clients and) servers must do with respect to a RESOURCE that 
they then store that entity in.  That's exactly what we need to specify 
in 2518's revision.

Note that I'm not advocating we should do anything other than the 
obvious: servers SHOULD always give back the same entity body type they 
were given for a resource (unless the client says it prefers a different 
type).  But there's a real question in my mind as to whether they MUST 
do this, and in any event even the SHOULD behavior is nowhere specified.

     dan

On Monday, February 18, 2002, at 04:08 AM, Julian Reschke wrote:

>> From: w3c-dist-auth-request@w3.org
>> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing
>> Sent: Monday, February 18, 2002 11:04 AM
>> To: Lisa Dusseault
>> Cc: w3c-dist-auth@w3c.org
>> Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC
>>
>>
>>
>> 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?
>
> No. As per RFC2616, 7.2.1: If and only if the media type is not given 
> by a
> Content-Type field, the recipient MAY
> attempt to guess the media type via inspection of its content and/or the
> name extension(s) of the URI used to identify
> the resource. If the media type remains unknown, the recipient SHOULD 
> treat
> it as type "application/octetstream".
>
>> 2. When a client creates a resource without mime type, should
>> the server make a guess or report application/octet-stream?
>
> It could, but I wouldn't recommend that. It may make sense to report a
> *specific* content type (such as application/x-foobar), but reporting
> "application/octet-stream" doesn't really help anybody.
>
>> 3. When a server reports application/octet-stream, should a client take
>> a guess in order to open an application/show an icon?
>
> No. See above.
>
>> 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
>
> Good question. RFC2616 forbids that.
>
>> a client know that the mime type was not "guessed" by the server?
>
> It can't. So it makes sense to let the server only guess if it's 
> reasonably
> sure that it's correct (and useful).
>
>>> 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.
>
> Wether or not a specific content type is valid for an empty resource 
> depends
> on the content type. I don't think that this needs to be treated 
> different
> from non-empty resources.
>
> Julian
>
>

Received on Monday, 25 February 2002 17:02:55 UTC