Subject: re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

From: Daniel Brotsky <[email-masked]>
Date: Thu, 14 Feb 2002 16:57:51 -0800

On Aug 17 last year, in 
<http://lists.w3.org/Archives/Public/w3c-dist-
auth/2001JulSep/0141.html>, Jason closed this issue using the Geoff's 
language about "act as if a PUT of length 0 happened."

Since I was on vacation at that time, I missed this conclusion, but 
don't worry: I agree with it!!  (phew :^)  But it raises a question 
(other than the 201 status response Lisa already raised) and I believe 
it closes another issue I rasied:

The question: what's the mime-type of the newly-created resource?

Now I know that many servers use file extensions to determine mime-type, 
so the name of the resource could be used to provide a mime-type.  But 
for other servers that expect clients to supply a Content-type header on 
PUT (or at least pay attention to them), what should happen?

My proposal: do not mandate behavior around this; leave the spec 
silent.  That way the spec is silent about mime-type of LOCK created 
resources exactly as it's silent about the mime type of PUT resources.

The issue: LOCK_URL_WITH_NO_PARENT_COLLECTION

In <http://lists.w3.org/Archives/Public/w3c-dist-
auth/2001JanMar/0134.html> I asked that LOCK return 409 with no body 
when parent collections don't exist.  There was no discussion (which at 
the time I took to be assent but the issue was never closed), but with 
this change in LOCK semantics I believe the issue is forced: LOCK must 
return 409 (with no body) exactly as PUT does when there are missing 
parent collections.  So I think this issue should be closed as accepted, 
unless anyone has a problem with the language I specified in my original 
message.

     dan

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 15 Feb 2002 09:40:06 +0100

Am Freitag den, 15. Februar 2002, um 01:57, schrieb Daniel Brotsky:

> On Aug 17 last year, in <http://lists.w3.org/Archives/Public/w3c-dist-
> auth/2001JulSep/0141.html>, Jason closed this issue using the 
> Geoff's language about "act as if a PUT of length 0 happened."
>
> Since I was on vacation at that time, I missed this conclusion, 
> but don't worry: I agree with it!!  (phew :^)  But it raises a 
> question (other than the 201 status response Lisa already raised) 
> and I believe it closes another issue I rasied:
>
> Now I know that many servers use file extensions to determine 
> mime-type, so the name of the resource could be used to provide a 
> mime-type.  But for other servers that expect clients to supply a 
> Content-type header on PUT (or at least pay attention to them), 
> what should happen?
>
> silent.  That way the spec is silent about mime-type of LOCK 
> created resources exactly as it's silent about the mime type of 
> PUT resources.

Yesterday we had internally the discussion about the mime-type of
a resource with length 0. I think we did not come to a good conclusion
and the whole mime-type handling is a mess anyway.

The only thing we could agree upon is that a client supplied mime-type
on PUT should be persistet (if possible) and override any name extension
guesswork.

> auth/2001JanMar/0134.html> I asked that LOCK return 409 with no 
> body when parent collections don't exist.  There was no discussion 
> (which at the time I took to be assent but the issue was never 
> closed), but with this change in LOCK semantics I believe the 
> issue is forced: LOCK must return 409 (with no body) exactly as 
> PUT does when there are missing parent collections.  So I think 
> this issue should be closed as accepted, unless anyone has a 
> problem with the language I specified in my original message.

Returning 409 sounds reasonable.

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sat, 16 Feb 2002 19:19:28 -0800

> on PUT should be persistet (if possible) and override any name extension

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 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?

Lisa

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 18 Feb 2002 11:03:51 +0100

> will definitely be consistent.  What's the virtue of not specifying it?

Can we specify answers for all questions below?

1. When a client creates a resource with 
"application/octet-stream", should
the server make a guess and replace octet-stream with another mime type?

2. When a client creates a resource without mime type, should
the server make a guess or report application/octet-stream?

3. When a server reports application/octet-stream, should a client take
a guess in order to open an application/show an icon?

4. When a server reports another mime type, is a client allowed to take
a guess anyway and disregard the server supplied mime type? How does
a client know that the mime type was not "guessed" by the server?

> always the case, whether the resource was previously empty or not?

Yes. The question is more what content-type to report on an empty 
resource.

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 18 Feb 2002 13:08:15 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Stefan Eissing
> Sent: Monday, February 18, 2002 11:04 AM
> To: Lisa Dusseault
> Cc: [email-masked]
> Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC
>
>
>

No. As per RFC2616, 7.2.1: 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/octetstream".

> the server make a guess or report application/octet-stream?

It could, but I wouldn't recommend that. It may make sense to report a
*specific* content type (such as application/x-foobar), but reporting
"application/octet-stream" doesn't really help anybody.

> a guess in order to open an application/show an icon?

No. See above.

> a guess anyway and disregard the server supplied mime type? How does

Good question. RFC2616 forbids that.

> a client know that the mime type was not "guessed" by the server?

It can't. So it makes sense to let the server only guess if it's reasonably
sure that it's correct (and useful).

> Yes. The question is more what content-type to report on an empty

Wether or not a specific content type is valid for an empty resource depends
on the content type. I don't think that this needs to be treated different
from non-empty resources.

Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 18 Feb 2002 15:29:17 +0100

Hi,

currently RFC2518 is silent on this issue.

However, deltaV says 1.5 [1]: "Although WebDAV request and response bodies
can be extended by arbitrary XML elements, which can be ignored by the
message recipient, an XML element in the DAV namespace MUST NOT be used in
the request or response body of a versioning method unless that XML element
is explicitly defined in an IETF RFC."

I think something similar needs to be added to the revision to RFC2518.

Looking at current implementations I notice that the Microsoft Webfolder
client (sigh!) does a PROPFIND on no less than then 10 proprietary
properties placed into the DAV: namespace ([2]), of which it only seems to
*use* one (DAV:ishidden). Without wiring special knowledge about these
attributes into a server, it will usually have to consult the resource's
dead properties (just to find out that these don't exist). Would it be
permissible to assume that properties in the DAV: namespace *never* are dead
properties, allowing to skip this step?

Julian

[1]
<http://www.webdav.org/deltav/protocol/draft-ietf-deltav-versioning-20.1.htm
#_Toc524830510>
[2]
<http://www.greenbytes.de/tech/webdav/webdavfaq.html#ANSWER-mswebfolder-prop
rietary-properties>

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 18 Feb 2002 07:57:16 -0800

> "application/octet-stream" doesn't really help anybody.

I'm not sure this is workable.  You're right that defaulting to
application/octet-stream doesn't help anybody, but it may hurt less.  When a
client creates a resource without a MIME type, then a client asks for the
resource using GET, the server must put some value in the Content-Type
header.  Since "getcontenttype" is defined as the type that would be
returned in the Content-Type header were the client to do a GET request, it
must have the same value.

This isn't a DAV problem only -- any Web server might have the same problem.

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 19 Feb 2002 08:43:34 +0100

> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Monday, February 18, 2002 4:57 PM
> To: Webdav WG; Julian Reschke
> Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC
>
>

No, it doesn't (as far as I can tell). RFC2616 says that the Content-Type
SHOULD be present, but then goes on saying what a recipient is allowed to do
when it's absent. So if you PUT without content type, cou can't *expect*
that the magically will invent one.

> This isn't a DAV problem only -- any Web server might have the

Right, that's why RFC2616 is relevant.

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 19 Feb 2002 08:45:49 +0100

> Sent: Sunday, February 17, 2002 4:19 AM
> To: Stefan Eissing; [email-masked]
>...

Because GET, PUT and content types are HTTP/1.1. So there's no point trying
to redefine something in WebDAV when it's not required.

---

From: Daniel Brotsky <[email-masked]>
Date: Mon, 25 Feb 2002 13:42:03 -0800

(Apologies for the late reply; I've been on vacation.)

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

> 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

---

From: Daniel Brotsky <[email-masked]>
Date: Mon, 25 Feb 2002 13:54:12 -0800

I think we're all very interested in the same questions (see my other 
note in this thread).  But I think we need a new issue for it, rather 
than discussing it as part of the lock-null issue.  I think LOCK-based 
resource creation should work just like PUT-based creation does, and the 
spec should simply say that.  This discussion about PUT and GET behavior 
should go with PUT.

     dan

On Monday, February 18, 2002, at 02:03 AM, Stefan Eissing wrote:

> 1. When a client creates a resource with "application/octet-stream", 
> should

---

From: Daniel Brotsky <[email-masked]>
Date: Mon, 25 Feb 2002 14:03:18 -0800

Ah, but there's a real subtlety here.  2616 only gives rules regarding 
the determination of the MESSAGE's entity body type; it says nothing 
about what (clients and) servers must do with respect to a RESOURCE that 
they then store that entity in.  That's exactly what we need to specify 
in 2518's revision.

Note that I'm not advocating we should do anything other than the 
obvious: servers SHOULD always give back the same entity body type they 
were given for a resource (unless the client says it prefers a different 
type).  But there's a real question in my mind as to whether they MUST 
do this, and in any event even the SHOULD behavior is nowhere specified.

     dan

---

From: Daniel Brotsky <[email-masked]>
Date: Mon, 25 Feb 2002 14:04:53 -0800

> I think something similar needs to be added to the revision to RFC2518.

I agree.

> properties, allowing to skip this step?

I think so.

     dan