RE: RFC2518bis issue: content type for locked empty resource

OK, I've fixed this.  Draft -04 will specify that servers MUST not choose a
Content-Type for a locked empty resource created through a LOCK command.
Also, I added this paragraph in section 7.4:

 
"The client is expected to update the locked empty resource shortly after
locking it, using PUT and possibly PROPPATCH.  When the client uses PUT to
overwrite a locked empty resource the client MUST supply a Content-Type if
any is known.  If the client supplies a Content-Type value the server MUST
set that value (this requirement actually applies to any resource that is
overwritten but is particularly necessary for locked empty resources which
are initially created with no Content-Type.  "

Lisa

-----Original Message-----
From: Geoffrey M Clemm [mailto:geoffrey.clemm@us.ibm.com] 
Sent: Monday, June 23, 2003 6:04 AM
To: Julian Reschke
Cc: Lisa Dusseault; Webdav WG; w3c-dist-auth-request@w3.org
Subject: 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 
> 
> 
>

Received on Friday, 27 June 2003 16:18:18 UTC