[Bug 152] SHOULD_A_SERVER_DETERMINE_MIMETYPE_OF_CONTENT

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=152





------- Additional Comments From julian.reschke@greenbytes.de  2006-02-03 07:20 -------
OK, the requirement for no content type in ELRs is gone, thanks.

I still think that the whole issue still needs to be improved. Section 7.3
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-latest.html#rfc.section.7.3>)
now says:

--
In the "locked empty resource" model, which is now the recommended
implementation, a resource created with a LOCK is empty but otherwise behaves in
every way as a normal resource. It is essentially the same resource that would
result from a PUT request with an empty body where a Content-Type was not
specified, followed by a LOCK request to the same resource. A locked empty resource:

    * Can be read, deleted, moved, copied, and in all ways behave as a regular
resource, not a lock-null resource.
    * Appears as a member of its parent collection.
    * SHOULD NOT disappear when its lock goes away (clients must therefore be
responsible for cleaning up their own mess, as with any other operation or any
non-empty resource)
    * MAY NOT have values for properties like DAV:getcontentlanguage which
haven't been specified yet by the client.
    * Can be updated (have content added) with a PUT request.
    * MUST NOT be converted into a collection. The server MUST fail a MKCOL
request (as it would with a MKCOL request to any existing non-collection resource).
    * MUST have defined values for DAV:lockdiscovery and DAV:supportedlock
properties.
    * The response MUST indicate that a resource was created, by use of the "201
Created" response code (a LOCK request to an existing resource instead will
result in 200 OK). The body must still include the DAV:lockdiscovery property,
as with a LOCK request to an existing resource.
--


So it's repeating lots of stuff that is defined somewhere else, and does this
using RFC2119 terminology. As far as I can tell, this is simply bad spec
writing. All we should say is that an ELR is the same thing as an empty resource
that was then locked and leave it at that.

Furtermore, in Section 9.7.1
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-latest.html#rfc.section.9.7.1>):

--
A PUT request is the only way a client has to indicate to the server what
Content-Type a resource should have, and whether it should change if the
resource is overwritten. Thus, a client MUST provide a Content-Type for a new
resource if any is known, and a server SHOULD use the Content-Type header value
on any PUT request as the resource's type (unless security concerns or policy
dictates otherwise). If the client does not provide a Content-Type for a new
resource, the server MAY create a resource with no Content-Type assigned, or it
MAY attempt to assign a reasonable and legal Content-Type.
--

1) Why MUST a server provide the type when it is known? What interoperability
problem would arise if it didn't?

2) The last sentence needs to be rewritten without the uppercase MAYs. In
absence of a content type supplied by the client, the server basically can do
what it wants, this really doesn't require anything normative from RFC2518.

2b) That being said, I would support to say "servers SHOULD NOT use a default of
application/octet-stream when the client didn't supply a content type", because
in this case not returning a type would be better.




------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

Received on Friday, 3 February 2006 15:20:15 UTC