RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

> 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, 18 February 2002 07:08:26 UTC