- From: Daniel Brotsky <dbrotsky@adobe.com>
- Date: Mon, 25 Feb 2002 13:42:03 -0800
- To: "Lisa Dusseault" <lisa@xythos.com>
- Cc: "Stefan Eissing" <stefan.eissing@greenbytes.de>, <w3c-dist-auth@w3c.org>
(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 UTC