RE: RFC2518bis issue: content type for locked empty resource

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

Received on Sunday, 22 June 2003 09:47:28 UTC