- From: <bugzilla@soe.ucsc.edu>
- Date: Sat, 14 Jan 2006 12:51:37 -0800
- 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 UTC