W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2003

RFC2518bis issue: content type for locked empty resource

From: Lisa Dusseault <lisa@xythos.com>
Date: Sat, 21 Jun 2003 15:02:45 -0700
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Message-ID: <003e01c33840$d84f6490$fdcb90c6@lisalap>

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?

Received on Saturday, 21 June 2003 18:02:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:27 UTC