W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2002

Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

From: Daniel Brotsky <dbrotsky@adobe.com>
Date: Mon, 25 Feb 2002 13:42:03 -0800
Cc: "Stefan Eissing" <stefan.eissing@greenbytes.de>, <w3c-dist-auth@w3c.org>
To: "Lisa Dusseault" <lisa@xythos.com>
Message-Id: <81CFCE43-2A38-11D6-8A37-0003931036B4@adobe.com>
(Apologies for the late reply; I've been on vacation.)

On Saturday, February 16, 2002, at 07:19 PM, Lisa Dusseault wrote:
> Application/octet-stream is the generally accepted "don't know what 
> else to
> use" MIME type, the default MIME type.  At least if we specify it, 
> behavior
> will definitely be consistent.  What's the virtue of not specifying it?

I think there are three cases when you lock a URL that has no associated 
resource:

1. User specifies a Content-type: header on the request.  In this case I 
believe the server SHOULD use that as the mime type of the associated 
0-length (newly created) resource.  (Interestingly, this is not mandated 
for a PUT in the spec; see below.)

2. User does not specify a Content-type: header on the request, but the 
server feels it can guess a mime type from the URL itself (e.g., the URL 
is /foo.html).  In this case the server MAY use the 
heuristically-determined mime type for the newly created resource.

3. User does not specify a Content-type: header on the request, and the 
server doesn't feel it can guess a mime type.  In this case the server 
MAY choose to associate application/octet-stream with the resource, but 
I believe it MAY also choose to associate NO mime type with the 
resource.  In this latter case the server could return a 204 (with no 
Content-Type: header) to any GET request.

> I do agree that when a content-type is included in a PUT overwriting the
> empty resource, that should become the new content-type.  However isn't 
> that
> always the case, whether the resource was previously empty or not?

Interestingly, 2518 says absolutely nothing about this.  I personally 
believe it's a fairly important interoperability issue (since it 
determines what clients can assume about how servers store their 
resource).  I'd love to see an issue added about it, especially since it 
would give us a chance to discuss whether the SHOULD in point 1, above, 
ought to be a MUST.

     dan
Received on Monday, 25 February 2002 16:41:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:59 GMT