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: Sat, 14 Jan 2006 12:51:37 -0800
Message-Id: <200601142051.k0EKpbdJ023848@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
----------------------------------------------------------------------------
         AssignedTo|julian.reschke@greenbytes.de|elias@cse.ucsc.edu



------- Additional Comments From julian.reschke@greenbytes.de  2006-01-14 12:51 -------
(Note that this also involved fixing the description of locked, empty resources,
and the definition of DAV:getcontenttype).

Proposed changes (see also
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz152>):

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.


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.


Section 7., para. 45:
OLD:

    o  Can be updated (have content added) with a PUT request.  The
       server MUST be able to set the content type as specified in the
       PUT request.

NEW:

    o  Can be updated (have content added) with a PUT request.


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.  If the client supplies a Content-
    Type value the server MUST set that value (this requirement actually
    applies to any resource that is overwritten but is particularly
    necessary for locked empty resources which are initially created with
    no Content-Type).

NEW:

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


Section 8., para. 145:
OLD:

 8.8.2  PUT for Collections

NEW:

    Note that although a recipient should treat metadata supplied with an
    HTTP request as authorative, in practice there's no guarantee that a
    server will take headers such as "Content-Type" into account.  In
    fact, returning the same Content-Type header as supplied with PUT in
    a subsequent GET request could be abused by malevolent clients to
    bypass content type based checks in other user agents.  Furthermore,
    many servers do not allow configuring the Content-Type on a per-
    resource basis in the first place.  Thus, clients should not rely on
    the ability to directly influence the content type by including a
    Content-Type request header.
 
 8.8.2  PUT for Collections



Section 14., para. 45:
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).





------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Saturday, 14 January 2006 20:51:41 GMT

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