On 2010-07-23 19:33, Thorsten Steinbrenner wrote:
> figured out, that I probably have a problem with my WebDAV server and
> not with a bug of Zotero itself ("It's your WebDAV server, not Zotero.
> The server is returning a 204, and the timestamp isn't changing.").
Hmmm...
204 is a success answer.
RFC2616 (HTTP):
9.6 PUT:
---8<---
If an existing resource is modified, either the 200 (OK) or 204 (No
Content) response codes SHOULD be sent to indicate successful completion
of the request.
---8<---
10.2.5 204 No Content:
---8<---
The server has fulfilled the request but does not need to return an
entity-body, and might want to return updated metainformation. The
response MAY include new or updated metainformation in the form of
entity-headers, which if present SHOULD be associated with the requested
variant.
---8<---
So if the a file with the same name as that sent with PUT allready
exists, the 204 answer is correct.
RFC4918 (WebDAV):
9.7.1 PUT for Non-Collection Resources:
---8<---
Properties defined on the resource may be recomputed during PUT
processing but are not otherwise affected.
---8<---
15.7 getlastmodified Property:
---8<---
Contains the Last-Modified header value (from Section 14.29 of
[RFC2616]) as it would be returned by a GET method without accept headers.
---8<---
The last-modified date on a resource SHOULD only reflect changes in the
body (the GET responses) of the resource.
---8<---
My interpretation of this is that
1) the server cannot be trusted to update properties such as time stamps
when modifying the content of a resource. I might be a very good idea,
but not a requirement.
2) A put of a zero size file to an existing zero size file might not be
considered a change int the body of the resource by all servers.
The proper (untested by me) way to do this in DAV probably is to use the
PROPPATCH method to set the time stamps (creationdate and
getlastmodified properties), and use PROPFIND to check them.
Using PROPPATCH would be the equivalent of using the "touch" command
line utility. If it works.
> apfel:~ ts$ curl -T empty -u zotero:secret --verbose
[output snipped]
Assuming that <http://abc.d/zotero/empty> allready existed as that
command was executed I see nothing wrong in either the request or the
answer in that transaction.
I can't know wether the Date header in the answer is correct or not, but
note how RFC2616 uses MAY and SHOULD with relation to the 204 answer.
This means that the client can't really trust that the Date header in
the answer contains the new time stamp of the uploaded file.
Regards
/Jonas
--
Jonas Eckerman
Fruktträdet & Förbundet Sveriges Dövblinda
http://www.fsdb.org/
http://www.frukt.org/
http://whatever.frukt.org/
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|