Thanks a lot for your detailed explanation!!! May I quote you on a
discussion about the topic on zotero.org?
Regards,
Thorsten
Am 23.07.10 22:10, schrieb Jonas Eckerman:
> 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
---------------------------------------------------------------------
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
|