Subject: RFC2518bis issue: content type for locked empty resource

From: "Lisa Dusseault" <[email-masked]>
Date: Sat, 21 Jun 2003 15:02:45 -0700

One of the remaining issues on how lock-null resources have been replaced by locked empty resources (resources whose behavior is normal, rather than different, and just happen to be locked and empty) is what Content-Type to use.  I had previously favoured a specific Content-type just so all servers behaved identically, and that's what most recently appears in the draft.  However, Julian's arguments are swaying me.  Here's our recent exchange on this subject:

> > > 7.4.: "SHOULD default to a content-type of 
> > > "application/octet-stream". "
> > >
> > > No. I don't think there's consensus for that, and requiring a 
> > > specific content type seems to have no value at all to 
> clients (see 
> > > also 8.11, "Locking Unmapped URLs").
> >
> > We disagree.  I find that specificity improves the 
> interoperability of 
> > a standard.  Nobody has explained why specificity hurts in 
> this case.
> 
> But in fact, nobody has stated how it helps either. For all 
> practical purposes, clients will treat 
> application/octet-stream and a missing content type the same 
> way. However, when there is no content type header, a client 
> is *allowed* to guess, while it's not allowed to do that when 
> it's present.
> 

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."

Does this violate HTTP -- IOW, does HTTP require a content-type for all resources? Is that requirement a theoretical, or practical requirement, or neither? 

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?

Another idea occurred to me that we could define a content-type specifically for "unknown" or "empty" body though that would have more ramifications.

What else needs to be said?

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 22 Jun 2003 15:47:06 +0200

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 23 Jun 2003 09:03:53 -0400

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:

> "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.
> 
> 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.
> 
> 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]:
> 
> 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
>

---

From: "Lisa Dusseault" <[email-masked]>
Date: Fri, 27 Jun 2003 13:18:26 -0700

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:[email-masked]] 
Sent: Monday, June 23, 2003 6:04 AM
To: Julian Reschke
Cc: Lisa Dusseault; Webdav WG; [email-masked]
Subject: RE: RFC2518bis issue: content type for locked empty resource

Cheers, 
Geoff