RE: RFC2518bis issue: content type for locked empty resource

I agree that server should return null content-type,
until the client has explicitly specified what it should be
(i.e. it should not default to some spec-specified or
server-specified type).

Cheers,
Geoff

Julian wrote on 06/22/2003 09:47:06 AM:

> 
> Lisa,
> 
> > ...
> > I hadn't thought that a client ought to know when it may guess 
> > the content-type. OTOH, there is no content-type to guess, so I'm 
> > not sure it helps to leave it null.  So here's some possible new 
language:
> > 
> > A locked empty resource:
> > "SHOULD default to a null content-type.  When the client sends a 
> > PUT request to overwrite the empty resource with a body the 
> > client SHOULD provide the correct content-type, and the server 
> > MUST then set the content-type."
> 
> I think the new wording would be much better.
> 
> > Does this violate HTTP -- IOW, does HTTP require a content-type 
> > for all resources? Is that requirement a theoretical, or 
> > practical requirement, or neither? 
> 
> From [1]:
> 
> "Any HTTP/1.1 message containing an entity-body SHOULD include a 
> Content-Type header field defining the media type of that body. 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/octet-stream". "
> 
> This sounds to me like a client MUST NOT ever guess the content type
> when it's supplied by the server. Thus the server should not try to 
> guess the type itself, unless it happen to know it.
> 
> > Should we discuss elsewhere whether a resource may exist with a 
> > null content-type and a non-zero length body?  Should we discuss 
> > what the client or server do in that case?
> 
> I think that is the same discussion. If we can agree on the fact 
> that an absent content type is better than a "guessed" content type,
> this will automatically apply to those empty resources created by 
> LOCK as well.
> 
> > Another idea occurred to me that we could define a content-type 
> > specifically for "unknown" or "empty" body though that would have 
> > more ramifications.
> 
> No no no. If the server doesn't know the content type, don't guess. 
> The client may know more than the server. However, if the server 
> starts guessing, a client MUST NOT try to guess on it's own. See [2]:
> 
> "The following are the key architectural points of this finding:
> 
> 1. MIME headers sent by a server are authoritative. [Design choice]
> 2. User agent behavior that misrepresents the user or the server is 
> harmful. [Principle]"
> 
> > What else needs to be said?
> 
> I'm not sure how interoperability is improved by mandating a 
> specific content type. An empty resource created by LOCK doesn't 
> have entity body yet, so the question about the content type is 
> really moot. Nobody knows until such time that the client actually 
> PUTs something. 
> 
> Julian
> 
> [1] <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.7.2.1>
> [2] <http://www.w3.org/2001/tag/doc/mime-respect.html>
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 
> 
> 
>