You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by LuKreme <kr...@kreme.com> on 2010/07/22 21:35:56 UTC
[users@httpd] Re: mod_webdav problem
On 21-Jul-2010, at 14:38, Thorsten Steinbrenner wrote:
>
> problem is, that the webdav server does NOT update the timestamp after a "HTTP PUT".
Um… I don't see this. When I copy a file to the webdav server it gets the time stamp of the time it was created on the server.
If you need to change the timestamp to something else, you can use touch -t on the server.
What is the issue?
--
'But you ain't part of it, are you?' said Granny conversationally. 'You
try, but you always find yourself watchin' yourself watchin' people, eh?
Never quite believin' anything? Thinkin' the wrong thoughts?'
--Maskerade
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: mod_webdav problem
Posted by Jonas Eckerman <jo...@frukt.org>.
On 2010-07-23 16:18, Thorsten Steinbrenner wrote:
> If the file is empty the timestamp is NOT updated:
This does make some kind of sense. The file allready existed with size
zero, so when your server got a PUT request with the same file with size
zero it never updated the file. After all, it didn't have to since it
was allready an empty file.
Wether this is by design, or wether it's an unintended result of how
apache handles PUT requests with content-size zero, is another question.
The obvious workaround is to PUT a file containing the current
timestamp, so that the content is actually modified when the file is
updated.
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
[users@httpd] Re: mod_webdav problem
Posted by Thorsten Steinbrenner <ne...@billroth.de>.
Am 23.07.10 21:08, schrieb Joost de Heer:
> I don't think this is a bug. Why would DAV have to do anything if a file
> with 0 bytes should be replaced by a file with 0 bytes?
<irony>
...to update this f*** timestamp... SCNR.... ;-)
</irony>
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
[users@httpd] Re: mod_webdav problem
Posted by Doug McNutt <do...@macnauchtan.com>.
At 16:32 -0600 7/23/10, LuKreme wrote:
>That is one way to look at it. The other way to look at it is that the date stamps on the file are also part of the file, and that since these changed the file should be replaced with the correct file, including the correct metadata.
For the sake of the archives and the next user who gets hooked:
1) A PUT request, which includes a Content-Length: 0 header, to send a file of zero length is read by Apache or its add-ins as a no-operation. Apache does not look at any existing file or its metadata. It simply returns a 204 code indicating zero content and quits. An existing file containing data of non-zero length will not be changed in any way.
2) A PUT request to send a file with non zero length will replace the contents of an existing file with the new or create a new file to hold the new data. In either case the operating system will adjust the time meta data the way it does for everyone else. Apache does not make any attempt to reset the meta data to reflect the actual time of receipt. Apache does not compare the old file content with the new to be sure the PUT request represented a bone-fide change to the data.
3) A PUT request to replace the contents of an existing file, of non-zero length, with a file of zero length is impossible even though that would seem to be a bona-fide change of content.
4) A PUT request to create a new file of zero length is impossible.
5) Items 1 through 3 are known to be treated the same way for at least, all UNIX-like systems, Apple OS neXt, and Windows.
.Now would someone look at those conclusions and complain or correct if they're not right?
--
--> Evolution made it possible for mankind to invent religion. <--
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
[users@httpd] Re: mod_webdav problem
Posted by LuKreme <kr...@kreme.com>.
On 23-Jul-2010, at 13:08, Joost de Heer wrote:
>
>>> < Server: Apache/2.2.8 (Ubuntu) DAV/2 mod_python/3.3.1 Python/2.5.2
>
>> The Server: HTTP header doesn't mention mod_webdav.
>
> It does: DAV/2
>
> I don't think this is a bug. Why would DAV have to do anything if a file with 0 bytes should be replaced by a file with 0 bytes?
That is one way to look at it. The other way to look at it is that the date stamps on the file are also part of the file, and that since these changed the file should be replaced with the correct file, including the correct metadata.
--
And Super Heroes come to feast
To taste the flesh not yet deceased
And all I know is still the beast is feeding.
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: mod_webdav problem
Posted by Joost de Heer <jo...@sanguis.xs4all.nl>.
>> < Server: Apache/2.2.8 (Ubuntu) DAV/2 mod_python/3.3.1 Python/2.5.2
> The Server: HTTP header doesn't mention mod_webdav.
It does: DAV/2
I don't think this is a bug. Why would DAV have to do anything if a file
with 0 bytes should be replaced by a file with 0 bytes?
Joost
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
[users@httpd] Re: mod_webdav problem
Posted by Thorsten Steinbrenner <ne...@billroth.de>.
Am 23.07.10 21:14, schrieb Thorsten Steinbrenner:
> That is probably true. There is absolutely nothing in Apache's logs
> because Apache did not even start to process the request.
Sorry, I must correct myself. That is what's in the logs, regardless of
the file size:
zotero [23/Jul/2010:21:33:36 +0200] "PUT /zotero/empty HTTP/1.1" 204 -
"-" "curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7
OpenSSL/0.9.8l zlib/1.2.3"
Not very exciting I think...
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
[users@httpd] Re: mod_webdav problem
Posted by Thorsten Steinbrenner <ne...@billroth.de>.
Am 23.07.10 21:38, schrieb Doug McNutt:
> In any case RFC2616 is required reading before arguing about bug or
> no bug.
Wow, that's hard stuff for me. I'm neither a programmer nor a native
speaker....
> Why do I feel like I'm reading something that came out of the US
> House of Representatives?
LOL, it could also be a paper from the German Bundestag... ;-)
BTW, it seems to work now since the size of the file is not zero
anymore!!! :-)
I still don't really understand it, but Apache/WebDAV seems to only
update the timestamp of an existing file, if the file size is not zero.
I don't know if this is a bug or a feature....
Thanks a lot for your help!!!
Regards,
Thorsten
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
[users@httpd] Re: mod_webdav problem
Posted by Doug McNutt <do...@macnauchtan.com>.
At 21:14 +0200 7/23/10, Thorsten Steinbrenner wrote:
>A bunch
< http://www.ietf.org/rfc/rfc2616.txt>
Section 9 describes the HTTP/1.1 PUT request on page 54.
>HTTP/1.1 does not define how a PUT method affects the state of an origin server.
>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. If the resource
could not be created or modified with the Request-URI, an appropriate
error response SHOULD be given that reflects the nature of the
problem.
That's not clear to me. It seems to say that the 204 reply indicates success but there was no continue-100 sent in reply to curl's Expect: header. That's in section 8 of the RFC. But it does seem to imply that "not modified" means "content not modified".
In any case RFC2616 is required reading before arguing about bug or no bug.
Why do I feel like I'm reading something that came out of the US House of Representatives?
--
--> From the U S of A, the only socialist country that refuses to admit it. <--
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
[users@httpd] Re: mod_webdav problem
Posted by Thorsten Steinbrenner <ne...@billroth.de>.
Am 23.07.10 20:46, schrieb Doug McNutt:
> It doesn't look like a problem with the curl tool. It attempted an
> HTTP PUT request and properly told the server that the file length
> was zero. Libcurl has its own list
> <http://cool.haxx.se/mailman/listinfo/curl-library>. If mod_webdav
> uses the curl library that would be a place to look.
>
> But your curl tool call clearly went to port 80 and was processed by
> WebDAV probably in the mod_webdav addition. That was where the 204
> rejection came from. Apache, or the mod, refused to complete, or even
> start processing with a continue reply, the request because no file
> content (zero length) was going to be sent. It sounds like a bug to
> me though reasonable folks might disagree.
That is probably true. There is absolutely nothing in Apache's logs
because Apache did not even start to process the request.
If it is a "bug" within mod_webdav, where can I ask for help about this
mod? I don't think there is a seperate webpage or mailing list dealing
with this mod?!?
> The Server: HTTP header doesn't mention mod_webdav. Are we sure it's
I'm quite sure since (this might sound stupid) I can "mount" the
directory with r/w access on the server with my Mac's finder ("Connect
to server...").
> there? Those things are out of my expertise. Could you be getting to
> a different instance of Apache?
Unfortunately not. Well, ok, I could try to configure WebDAV on my Mac.
> Does mod-webdav put out any log files? I'm out of my chosen field
> there. Can you put a couple of nulls in the "empty file" without
> messing up your Zotero interface? date > empty ?
Dan Stillman was so kind to change Zotero a bit. The "lastsync" file now
contains a single space. I'll try this tomorrow first. I'll tell you
what happend....
Regards,
Thorsten
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
[users@httpd] Re: mod_webdav problem
Posted by Doug McNutt <do...@macnauchtan.com>.
At 19:33 +0200 7/23/10, Thorsten Steinbrenner wrote:
>Again, thanks a lot for your help! My problem is, that I use the WebDAV
>server to sync with zotero (http://www.zotero.org). Zotero uses WebDAV
>to store attachments for library items. This is why I have to use WebDAV
>and unfortunately not SSH or FTP... :-(
>
>Since the sync did not work properly I asked for help on Zotero support
>forum. Dan Stillman (one of the "brains" and programmers behind Zotero)
>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."). I
>assume that Zotero uses libcurl to update the file "lastsync" since he
>suggested to use curl to test the issue ("You should be able to test
>this with your server with curl, at any rate."). This is why I (1) use
>curl to test and (2) use WebDAV at all...
>
>curl with --verbose:
>
>apfel:~ ts$ curl -T empty -u zotero:secret --verbose
>http://abc.d/zotero/empty
>* About to connect() to abc.de port 80 (#0)
>* Trying 12.34.56.78... connected
>* Connected to abc.de (12.34.56.78) port 80 (#0)
>* Server auth using Basic with user 'zotero'
>> PUT /zotero/empty HTTP/1.1
>> Authorization: Basic xyz==
>> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7
>OpenSSL/0.9.8l zlib/1.2.3
>> Host: abc.de
>> Accept: */*
>> Content-Length: 0
>> Expect: 100-continue
>>
>< HTTP/1.1 204 No Content
>< Date: Fri, 23 Jul 2010 17:14:29 GMT
>< Server: Apache/2.2.8 (Ubuntu) DAV/2 mod_python/3.3.1 Python/2.5.2
>PHP/5.2.4-2ubuntu5.10 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g
>< Content-Length: 0
>< Content-Type: text/plain
><
>* Connection #0 to host billroth.de left intact
>* Closing connection #0
>
>Do you think it is a curl issue? Then I would probably go ahead and ask
>for help on the curl mailing list....
It doesn't look like a problem with the curl tool. It attempted an HTTP PUT request and properly told the server that the file length was zero. Libcurl has its own list <http://cool.haxx.se/mailman/listinfo/curl-library>. If mod_webdav uses the curl library that would be a place to look.
But your curl tool call clearly went to port 80 and was processed by WebDAV probably in the mod_webdav addition. That was where the 204 rejection came from. Apache, or the mod, refused to complete, or even start processing with a continue reply, the request because no file content (zero length) was going to be sent. It sounds like a bug to me though reasonable folks might disagree.
The Server: HTTP header doesn't mention mod_webdav. Are we sure it's there? Those things are out of my expertise. Could you be getting to a different instance of Apache?
Does mod-webdav put out any log files? I'm out of my chosen field there. Can you put a couple of nulls in the "empty file" without messing up your Zotero interface? date > empty ?
--
--> Marriage and kilo are troubled words. Turmoil results when centuries-old usage is altered in specialized jargon <--.
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
[users@httpd] Re: mod_webdav problem
Posted by Thorsten Steinbrenner <ne...@billroth.de>.
THX a lot!
Am 24.07.10 19:00, schrieb Jonas Eckerman:
> On 2010-07-23 23:08, Thorsten Steinbrenner wrote:
>
>> Thanks a lot for your detailed explanation!!! May I quote you on a
>> discussion about the topic on zotero.org?
>
> Sure. If you do, please give them the complete mail I wrote and tell
> them that it's just my *interpretation* of the RFCs in question.
>
> It'd probably be better if they reread the RFCs themselves, keeping an
> eye out for everything relevant to this problem.
>
> 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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: mod_webdav problem
Posted by Jonas Eckerman <jo...@frukt.org>.
On 2010-07-23 23:08, Thorsten Steinbrenner wrote:
> Thanks a lot for your detailed explanation!!! May I quote you on a
> discussion about the topic on zotero.org?
Sure. If you do, please give them the complete mail I wrote and tell
them that it's just my *interpretation* of the RFCs in question.
It'd probably be better if they reread the RFCs themselves, keeping an
eye out for everything relevant to this problem.
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
[users@httpd] Re: mod_webdav problem
Posted by Thorsten Steinbrenner <ne...@billroth.de>.
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: mod_webdav problem
Posted by Jonas Eckerman <jo...@frukt.org>.
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
[users@httpd] Re: mod_webdav problem
Posted by Thorsten Steinbrenner <ne...@billroth.de>.
Again, thanks a lot for your help! My problem is, that I use the WebDAV
server to sync with zotero (http://www.zotero.org). Zotero uses WebDAV
to store attachments for library items. This is why I have to use WebDAV
and unfortunately not SSH or FTP... :-(
Since the sync did not work properly I asked for help on Zotero support
forum. Dan Stillman (one of the "brains" and programmers behind Zotero)
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."). I
assume that Zotero uses libcurl to update the file "lastsync" since he
suggested to use curl to test the issue ("You should be able to test
this with your server with curl, at any rate."). This is why I (1) use
curl to test and (2) use WebDAV at all...
curl with --verbose:
apfel:~ ts$ curl -T empty -u zotero:secret --verbose
http://abc.d/zotero/empty
* About to connect() to abc.de port 80 (#0)
* Trying 12.34.56.78... connected
* Connected to abc.de (12.34.56.78) port 80 (#0)
* Server auth using Basic with user 'zotero'
> PUT /zotero/empty HTTP/1.1
> Authorization: Basic xyz==
> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7
OpenSSL/0.9.8l zlib/1.2.3
> Host: abc.de
> Accept: */*
> Content-Length: 0
> Expect: 100-continue
>
< HTTP/1.1 204 No Content
< Date: Fri, 23 Jul 2010 17:14:29 GMT
< Server: Apache/2.2.8 (Ubuntu) DAV/2 mod_python/3.3.1 Python/2.5.2
PHP/5.2.4-2ubuntu5.10 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g
< Content-Length: 0
< Content-Type: text/plain
<
* Connection #0 to host billroth.de left intact
* Closing connection #0
Do you think it is a curl issue? Then I would probably go ahead and ask
for help on the curl mailing list....
Regards,
Thorsten
Am 23.07.10 18:16, schrieb Doug McNutt:
> At 16:18 +0200 7/23/10, Thorsten Steinbrenner wrote, and I snipped:
>> I played around a bit and figured out,
>> that the timestamp is updated if the file is not empty. If the file is
>> empty the timestamp is NOT updated:
>>
>> Client:
>>
>> apfel:~ ts$ echo "abc" > test
>> apfel:~ ts$ touch test
>> apfel:~ ts$ ls -l test
>> -rw-r--r-- 1 ts staff 4 23 Jul 15:54 test
>> apfel:~ ts$ curl -T test -u zotero:secret http://abc.de/zotero/test
>> (...waiting for 2 minutes...)
>> apfel:~ ts$ touch test
>> apfel:~ ts$ ls -l test
>> -rw-r--r-- 1 ts staff 4 23 Jul 15:56 test
>> apfel:~ ts$ curl -T test -u zotero:secret http://abc.de/zotero/test
>>
>> Server:
>>
>> root@abc:/etc/apache2# ls -l /var/zotero/test
>> -rw-r--r-- 1 www-data www-data 4 2010-07-23 15:54 test
>> root@abc:/etc/apache2# ls -l /var/zotero/test
>> -rw-r--r-- 1 www-data www-data 4 2010-07-23 15:56 test
>>
>> However, it does _not_ work if the file is empty:
>>
>> Client:
>>
>> apfel:~ ts$ touch empty
>> apfel:~ ts$ ls -l empty
>> -rw-r--r-- 1 ts staff 0 23 Jul 16:03 empty
>> apfel:~ ts$ curl -T empty -u zotero:secret http://abc.de/zotero/empty
>> (...waiting for 2 minutes...)
>> apfel:~ ts$ touch empty
>> apfel:~ ts$ ls -l empty
>> -rw-r--r-- 1 ts staff 0 23 Jul 16:05 empty
>> apfel:~ ts$ curl -T empty -u zotero:secret http://abc.de/zotero/empty
>>
>> Server:
>>
>> root@abc:/etc/apache2# ls -l /var/zotero/empty
>> -rw-r--r-- 1 www-data www-data 0 2010-07-23 16:01 /var/zotero/empty
>> root@abc:/etc/apache2# ls -l /var/zotero/empty
>> -rw-r--r-- 1 www-data www-data 0 2010-07-23 16:01 /var/zotero/empty
>
> It's possible that curl is at least part of the problem.
> A couple of suggestions:
>
> What if the server file is not empty when the empty file is uploaded? Or was it that way?
>
> Try curl with the --verbose option set.
>
> Try curl using ftp: curl --verbose -T empty -u zotero:secret ftp://abc.de/var/zotero/empty
>
> Try using scp if it's supported and you want to spend time setting up required $HOME/.ssh files. With ssh you could actually "touch" the empty file.
>
> It's just possible that some software is being more helpful than you like. The curl mailing list is quite active and helpful. I don't know if curl uses your Apache server to accomplish an HTTP upload.
>
> List-Archive: <http://cool.haxx.se/pipermail/curl-users>
> List-Post: <ma...@cool.haxx.se>
> List-Help: <mailto:curl-users-request@cool.haxx.se?subject=help>
> List-Subscribe: <http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users>, <mailto:curl-users-request@cool.haxx.se?subject=subscribe>
>
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
[users@httpd] Re: mod_webdav problem
Posted by Doug McNutt <do...@macnauchtan.com>.
At 16:18 +0200 7/23/10, Thorsten Steinbrenner wrote, and I snipped:
>I played around a bit and figured out,
>that the timestamp is updated if the file is not empty. If the file is
>empty the timestamp is NOT updated:
>
>Client:
>
>apfel:~ ts$ echo "abc" > test
>apfel:~ ts$ touch test
>apfel:~ ts$ ls -l test
>-rw-r--r-- 1 ts staff 4 23 Jul 15:54 test
>apfel:~ ts$ curl -T test -u zotero:secret http://abc.de/zotero/test
>(...waiting for 2 minutes...)
>apfel:~ ts$ touch test
>apfel:~ ts$ ls -l test
>-rw-r--r-- 1 ts staff 4 23 Jul 15:56 test
>apfel:~ ts$ curl -T test -u zotero:secret http://abc.de/zotero/test
>
>Server:
>
>root@abc:/etc/apache2# ls -l /var/zotero/test
>-rw-r--r-- 1 www-data www-data 4 2010-07-23 15:54 test
>root@abc:/etc/apache2# ls -l /var/zotero/test
>-rw-r--r-- 1 www-data www-data 4 2010-07-23 15:56 test
>
>However, it does _not_ work if the file is empty:
>
>Client:
>
>apfel:~ ts$ touch empty
>apfel:~ ts$ ls -l empty
>-rw-r--r-- 1 ts staff 0 23 Jul 16:03 empty
>apfel:~ ts$ curl -T empty -u zotero:secret http://abc.de/zotero/empty
>(...waiting for 2 minutes...)
>apfel:~ ts$ touch empty
>apfel:~ ts$ ls -l empty
>-rw-r--r-- 1 ts staff 0 23 Jul 16:05 empty
>apfel:~ ts$ curl -T empty -u zotero:secret http://abc.de/zotero/empty
>
>Server:
>
>root@abc:/etc/apache2# ls -l /var/zotero/empty
>-rw-r--r-- 1 www-data www-data 0 2010-07-23 16:01 /var/zotero/empty
>root@abc:/etc/apache2# ls -l /var/zotero/empty
>-rw-r--r-- 1 www-data www-data 0 2010-07-23 16:01 /var/zotero/empty
It's possible that curl is at least part of the problem.
A couple of suggestions:
What if the server file is not empty when the empty file is uploaded? Or was it that way?
Try curl with the --verbose option set.
Try curl using ftp: curl --verbose -T empty -u zotero:secret ftp://abc.de/var/zotero/empty
Try using scp if it's supported and you want to spend time setting up required $HOME/.ssh files. With ssh you could actually "touch" the empty file.
It's just possible that some software is being more helpful than you like. The curl mailing list is quite active and helpful. I don't know if curl uses your Apache server to accomplish an HTTP upload.
List-Archive: <http://cool.haxx.se/pipermail/curl-users>
List-Post: <ma...@cool.haxx.se>
List-Help: <mailto:curl-users-request@cool.haxx.se?subject=help>
List-Subscribe: <http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users>, <mailto:curl-users-request@cool.haxx.se?subject=subscribe>
--
--> In Christianity, man can have only one wife. This is known as monotony. <--
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
[users@httpd] Re: mod_webdav problem
Posted by Thorsten Steinbrenner <ne...@billroth.de>.
Hi!
Thanks a lot for your answers!! I played around a bit and figured out,
that the timestamp is updated if the file is not empty. If the file is
empty the timestamp is NOT updated:
Client:
apfel:~ ts$ echo "abc" > test
apfel:~ ts$ touch test
apfel:~ ts$ ls -l test
-rw-r--r-- 1 ts staff 4 23 Jul 15:54 test
apfel:~ ts$ curl -T test -u zotero:secret http://abc.de/zotero/test
(...waiting for 2 minutes...)
apfel:~ ts$ touch test
apfel:~ ts$ ls -l test
-rw-r--r-- 1 ts staff 4 23 Jul 15:56 test
apfel:~ ts$ curl -T test -u zotero:secret http://abc.de/zotero/test
Server:
root@abc:/etc/apache2# ls -l /var/zotero/test
-rw-r--r-- 1 www-data www-data 4 2010-07-23 15:54 test
root@abc:/etc/apache2# ls -l /var/zotero/test
-rw-r--r-- 1 www-data www-data 4 2010-07-23 15:56 test
However, it does _not_ work if the file is empty:
Client:
apfel:~ ts$ touch empty
apfel:~ ts$ ls -l empty
-rw-r--r-- 1 ts staff 0 23 Jul 16:03 empty
apfel:~ ts$ curl -T empty -u zotero:secret http://abc.de/zotero/empty
(...waiting for 2 minutes...)
apfel:~ ts$ touch empty
apfel:~ ts$ ls -l empty
-rw-r--r-- 1 ts staff 0 23 Jul 16:05 empty
apfel:~ ts$ curl -T empty -u zotero:secret http://abc.de/zotero/empty
Server:
root@abc:/etc/apache2# ls -l /var/zotero/empty
-rw-r--r-- 1 www-data www-data 0 2010-07-23 16:01 /var/zotero/empty
root@abc:/etc/apache2# ls -l /var/zotero/empty
-rw-r--r-- 1 www-data www-data 0 2010-07-23 16:01 /var/zotero/empty
I need to use a sync software, that stores the date and time of the last
sync in an empty file called "lastsync". My problem ist that the
timestamp of this file is not updated properly.
THX again!
Thorsten
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
[users@httpd] Re: mod_webdav problem
Posted by Doug McNutt <do...@macnauchtan.com>.
At 13:35 -0600 7/22/10, LuKreme wrote:
>On 21-Jul-2010, at 14:38, Thorsten Steinbrenner wrote:
>>
>> problem is, that the webdav server does NOT update the timestamp after a "HTTP PUT".
>
>Um I don't see this. When I copy a file to the webdav server it gets the time stamp of the time it was created on the server.
>
>If you need to change the timestamp to something else, you can use touch -t on the server.
>
>What is the issue?
And what is the operating system on which Apache is running?
Can you access the directory with anything else but an HTTP request? A terminal session? Anything else that would show the time tags while bypassing Apache.
It's hard to believe that Apache deliberately overrides operating system defaults which almost surely set the modification timestamp when the file is changed.
Is it possible that Apache is cashing the file? If you wait a while do you see a changed time?
--
--> A fair tax is one that you pay but I don't <--
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org