> When sending files to a zope 2.10.6 folder, the write takes many
> attempts and minutes to complete, using davfs2/neon client.
>
> After a PUT is received from the client, and In response to a HEAD-
> request for a non-existent resource, the Zope response includes a body,
> showing up as 404 messages in the z2 log. This is not allowed according
> to the RFC and seems to confuse neon, causing it to close the
> connection. This repeats, until for some reason, Zope responds with the
> correct status OK and then the file get written.
>
> What RFC 2616 says about HEAD and body:
>
> 9.4 HEAD
>
> The HEAD method is identical to GET except that the server MUST NOT
> return a message-body in the response.
>
I can't reproduce with the Zope 2.10 branch tip using cadaver, which
also uses libneon::
- -----------------------------------------------------------------
$ cd projects/Zope-CVS/Zope-2.10-branch/
$ bin/mkzopeinstance.py -d /tmp/lp239636 -u admin:admin
$ cd /tmp/lp239636/
$ bin/zopectl start
$ bin/zopectl logtail
2008-06-13T10:47:51 INFO ZServer HTTP server started at Fri Jun 13
10:47:51 2008
Hostname: 0.0.0.0
Port: 8080
- ------
2008-06-13T10:47:58 INFO Application New disk product detected,
determining if we need to fix up any ZClasses.
- ------
2008-06-13T10:47:58 INFO Zope Ready to handle requests
^c
$ echo "This is a test." > foo.txt
$ cadaver http://localhost:8080/
Authentication required for Zope on server `localhost':
Username: admin
Password:
dav:/> put foo.txt
Uploading foo.txt to `/foo.txt':
Progress: [=============================>] 100.0% of 16 bytes succeeded.
dav:/> cat foo.txt
Displaying `/foo.txt':
This is a test.
dav:/> cat not_there
Displaying `/not_there':
Failed: 404 Not Found
dav:/> ls
Listing collection `/': succeeded.
Coll: Control_Panel 0 Jun 13 10:47
Coll: temp_folder 0 Jun 13 10:47
acl_users 0 Jun 13 10:47 browser_id_manager 0 Jun 13 10:47
error_log 0 Jun 13 10:47
favicon.ico 22486 Jun 13 10:47
foo.txt 16 Jun 13 10:50
index_html 28 Jun 13 10:47 session_data_manager 0 Jun 13 10:47 standard_error_message 1227 Jun 13 10:47 standard_html_footer 18 Jun 13 10:47 standard_html_header 82 Jun 13 10:47 standard_template.pt 281 Jun 13 10:47 virtual_hosting 0 Jun 13 10:47
^D
$ dpkg-query --show libneon27
libneon27 0.27.2-1
$ dpkg-query --show cadaver
cadaver 0.23.0-1
- -----------------------------------------------------------------
If your HEAD request is returning a 404, then you have a different
problem (the resource is not there). AFAICT, the presence of the
response body is contra-spec, but has not caused any other issues that I
know of in the eight years I've been using DAV against Zope.
Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 <email address hidden>
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
jswinner wrote:
> When sending files to a zope 2.10.6 folder, the write takes many
> attempts and minutes to complete, using davfs2/neon client.
>
> After a PUT is received from the client, and In response to a HEAD-
> request for a non-existent resource, the Zope response includes a body,
> showing up as 404 messages in the z2 log. This is not allowed according
> to the RFC and seems to confuse neon, causing it to close the
> connection. This repeats, until for some reason, Zope responds with the
> correct status OK and then the file get written.
>
> What RFC 2616 says about HEAD and body:
>
> 9.4 HEAD
>
> The HEAD method is identical to GET except that the server MUST NOT
> return a message-body in the response.
>
I can't reproduce with the Zope 2.10 branch tip using cadaver, which
also uses libneon::
- ------- ------- ------- ------- ------- ------- ------- ------- ------- -- Zope-CVS/ Zope-2. 10-branch/ nce.py -d /tmp/lp239636 -u admin:admin localhost: 8080/ ======= ======= ======= ==>] 100.0% of 16 bytes succeeded.
browser_ id_manager 0 Jun 13 10:47
session_ data_manager 0 Jun 13 10:47
standard_ error_message 1227 Jun 13 10:47
standard_ html_footer 18 Jun 13 10:47
standard_ html_header 82 Jun 13 10:47
standard_ template. pt 281 Jun 13 10:47
virtual_ hosting 0 Jun 13 10:47 ------- ------- ------- ------- ------- ------- ------- ------- --
$ cd projects/
$ bin/mkzopeinsta
$ cd /tmp/lp239636/
$ bin/zopectl start
$ bin/zopectl logtail
2008-06-13T10:47:51 INFO ZServer HTTP server started at Fri Jun 13
10:47:51 2008
Hostname: 0.0.0.0
Port: 8080
- ------
2008-06-13T10:47:58 INFO Application New disk product detected,
determining if we need to fix up any ZClasses.
- ------
2008-06-13T10:47:58 INFO Zope Ready to handle requests
^c
$ echo "This is a test." > foo.txt
$ cadaver http://
Authentication required for Zope on server `localhost':
Username: admin
Password:
dav:/> put foo.txt
Uploading foo.txt to `/foo.txt':
Progress: [======
dav:/> cat foo.txt
Displaying `/foo.txt':
This is a test.
dav:/> cat not_there
Displaying `/not_there':
Failed: 404 Not Found
dav:/> ls
Listing collection `/': succeeded.
Coll: Control_Panel 0 Jun 13 10:47
Coll: temp_folder 0 Jun 13 10:47
acl_users 0 Jun 13 10:47
error_log 0 Jun 13 10:47
favicon.ico 22486 Jun 13 10:47
foo.txt 16 Jun 13 10:50
index_html 28 Jun 13 10:47
^D
$ dpkg-query --show libneon27
libneon27 0.27.2-1
$ dpkg-query --show cadaver
cadaver 0.23.0-1
- -------
If your HEAD request is returning a 404, then you have a different
problem (the resource is not there). AFAICT, the presence of the
response body is contra-spec, but has not caused any other issues that I
know of in the eight years I've been using DAV against Zope.
Tres. ======= ======= ======= ======= ======= ======= ======= ======= ==== palladion. com enigmail. mozdev. org
- --
=======
Tres Seaver +1 540-429-0999 <email address hidden>
Palladion Software "Excellence by Design" http://
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://
iD8DBQFIUo0B+ gerLs4ltQ4RAmfo AKCpRmsm0KSVnYS 6vDP5LlHFXTBEjw CgvoeP JT7b9pPxNtI=
LZQTdNxAkVT+
=jtfW
-----END PGP SIGNATURE-----