Upgrade StorageWebDAV on 4shared.com
I'm having difficulty using Zotero/WebDAV with 4shared.com's web server. Here is the logged output when i try to verify the server (note: I haven't created a zotero collection):
-- snip --
(3)(+0008169): Verifying storage
(3)(+0000001): Getting WebDAV password
(3)(+0000004): HTTP OPTIONS for https://nfitzkee:********@webdav.4shared.com/zotero/
(3)(+0000211): Server: Apache-Coyote/1.1
Set-Cookie: WWW_JSESSIONID=35B04B80D4F7B06BAB59D0BE7382F1A6.dc10331; Domain=.4shared.com; Path=/
Content-Type: text/html
Transfer-Encoding: chunked
Date: Thu, 12 May 2011 19:45:47 GMT
(3)(+0000000): <html><body><h1>/zotero/ Not Found (404)</h1></body></html>
(3)(+0000000): ===>404<===(number)
(4)(+0005608): Registering observer for [collection,search,share,group,bucket] in notifier with hash Rt'
(5)(+0000002): SELECT itemTypeID AS id, typeName AS name, custom FROM itemTypesCombined WHERE display=2
(5)(+0000001): SELECT itemTypeID AS id, typeName AS name, custom FROM itemTypesCombined WHERE display=1
-- snip --
It appears as though Zotero cannot find the /zotero collection. When I create the zotero collection manually, the same error message occurs.
Thinking that the 4shared implementation may be limited, I did some testing with the cadaver command. The following command works fine:
cadaver https://webdav.4shared.com/
Using that, I can navigate, upload, etc. But if I attempt to access the store using:
cadaver https://webdav.4shared.com/zotero/
This doesn't work; presumably 4shared is dying on the /zotero/ part. This may be why Zotero is also failing in my case. However, perhaps there's a workaround so that either (a) the /zotero/ directory can be changed (in my case to use the root WebDAV collection) or (b) zotero can connect first then change collection rather than requiring the entire address be on a single line.
Generally, if my hypothesis is correct, I'd suggest implementing both (a) and (b). For one, I'm not sure why the user should be limited to a particular collection in WebDAV. Secondly, it seems like implementing (b) would make the system more compatible in general.
Regards,
Nick
-- snip --
(3)(+0008169): Verifying storage
(3)(+0000001): Getting WebDAV password
(3)(+0000004): HTTP OPTIONS for https://nfitzkee:********@webdav.4shared.com/zotero/
(3)(+0000211): Server: Apache-Coyote/1.1
Set-Cookie: WWW_JSESSIONID=35B04B80D4F7B06BAB59D0BE7382F1A6.dc10331; Domain=.4shared.com; Path=/
Content-Type: text/html
Transfer-Encoding: chunked
Date: Thu, 12 May 2011 19:45:47 GMT
(3)(+0000000): <html><body><h1>/zotero/ Not Found (404)</h1></body></html>
(3)(+0000000): ===>404<===(number)
(4)(+0005608): Registering observer for [collection,search,share,group,bucket] in notifier with hash Rt'
(5)(+0000002): SELECT itemTypeID AS id, typeName AS name, custom FROM itemTypesCombined WHERE display=2
(5)(+0000001): SELECT itemTypeID AS id, typeName AS name, custom FROM itemTypesCombined WHERE display=1
-- snip --
It appears as though Zotero cannot find the /zotero collection. When I create the zotero collection manually, the same error message occurs.
Thinking that the 4shared implementation may be limited, I did some testing with the cadaver command. The following command works fine:
cadaver https://webdav.4shared.com/
Using that, I can navigate, upload, etc. But if I attempt to access the store using:
cadaver https://webdav.4shared.com/zotero/
This doesn't work; presumably 4shared is dying on the /zotero/ part. This may be why Zotero is also failing in my case. However, perhaps there's a workaround so that either (a) the /zotero/ directory can be changed (in my case to use the root WebDAV collection) or (b) zotero can connect first then change collection rather than requiring the entire address be on a single line.
Generally, if my hypothesis is correct, I'd suggest implementing both (a) and (b). For one, I'm not sure why the user should be limited to a particular collection in WebDAV. Secondly, it seems like implementing (b) would make the system more compatible in general.
Regards,
Nick
Implementing (a) isn't outside the realm of possibility, though it's not really a problem with a properly functioning WebDAV server.