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

[Bug 152] SHOULD_A_SERVER_DETERMINE_MIMETYPE_OF_CONTENT

From: <bugzilla@soe.ucsc.edu>
Date: Tue, 17 Jan 2006 10:54:59 -0800
Message-Id: <200601171854.k0HIsxv7006027@ietf.cse.ucsc.edu>
To: w3c-dist-auth@w3.org

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

julian.reschke@greenbytes.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |



------- Additional Comments From julian.reschke@greenbytes.de  2006-01-17 10:54 -------
I think there's more to do; below are the missing changes + rational.


Section 7., para. 31:
OLD:

    A successful lock request to an unmapped URL MUST result in the
    creation of an locked resource with empty content.  Subsequently, a
    successful PUT request (with the correct lock token) provides the
    content for the resource, and the server MUST also use the content-
    type and content-language information from this request.

NEW:

    A successful lock request to an unmapped URL MUST result in the
    creation of an locked resource with empty content.  Subsequently, a
    successful PUT request (with the correct lock token) provides the
    content for the resource.


If we know that servers won't accept the content type header, there's no point
claiming it's a MUST requirement, in particular not in the section about locks.



Section 7., para. 44:
OLD:

    o  SHOULD default to having no content type.
 
    o  MAY NOT have values for properties like DAV:getcontentlanguage
       which haven't been specified yet by the client.

NEW:

    o  MAY NOT have values for properties like DAV:getcontentlanguage
       which haven't been specified yet by the client.

Again: we can't force servers to do this.  If a server computes the mime type
based on the extension, this is what the mime type will be.


Section 7., para. 49:
OLD:

    The client is expected to update the locked empty resource shortly
    after locking it, using PUT and possibly PROPPATCH.  When the client
    uses PUT to overwrite a locked empty resource the client MUST supply
    a Content-Type if any is known.

NEW:

    The client is expected to update the locked empty resource shortly
    after locking it, using PUT and possibly PROPPATCH.

Why do we require this, and why is it a MUST?


Section 14., para. 42:
OLD:

    Protected:  SHOULD NOT be protected, so clients may fix this value.
       Note that servers implementing RFC2518 might have made this a
       protected property as this is a new requirement.

NEW:

    Protected:  Potentially protected if the server prefers to assign
       content types on it's own (see also discussion in Section 8.8.1).

DAV:getcontenttype is defined in terms of HTTP, and if we don't require servers
to accept the content-type upon PUT, then there's also no requirement to make
DAV:getcontenttype settable (same reasoning).




------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Tuesday, 17 January 2006 18:55:04 GMT

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