RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

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?

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?

Lisa

Received on Saturday, 16 February 2002 22:18:18 UTC