upload fails/gets stuck

rtc1
zotero gets stuck trying to upload certain attachments. This doesn't happen for many attachments (about about 1% of the time), but if it happens for one specific attachment, it's reproducible.

For example: Go to http://www.computer.org/portal/web/csdl/doi/10.1109/ACSD.2006.29 and click the "Save to zotero" icon in the URL bar. Now wait for zotero to attempt to sync. For me, it reproducibly gets stuck while trying to upload the snapshot attachment -- clicking the download stop button has no effect either, btw.

If I remove the snapshot attachment and empty the trash, the problem goes away. So it seems to be related to this specific attachment, in some way.

tested with firefox 13.0, zotero 3.0.7, both on fedora 17 and ubuntu 10.04.

I'm using WebDAV storage for my attachments, which is a zimbra briefcase.
  • dstillman
    Provide a Debug ID for a sync attempt that produces the error.
  • rtc1
    The Debug ID is D1886194901

    zotero://select/items/0_5Z94X4C6 selects exactly the snapshot attachment from the website I mentioned above.

    Bar popup says:

    Progress: 96%
    Downloads: 0
    Uploads: 25KB remaining (0/1 files)
  • dstillman
    (3)(+0000000): Invalid progress for request 'null/5Z94X4C6' (524286 < 524288)
    This is likely a problem with either your WebDAV server or your network (and/or a bug in Firefox, but we've never been able to reproduce it). For some reason Firefox is getting a different total size for the transfer, and so it never finishes the request.

    If this is a laptop, try from a different network.
  • aurimas
    Though since it's very reproducible on your system, maybe we can reproduce it as well. What WebDAV server are you using?
  • rtc1
    I already tried from different machines and different networks.

    It would be good for zotero to at least fail gracefully, with the "Cancel Storage Sync" button working, or even detecting the problem and giving a warning, instead of just spinning the green arrow over and over again ...

    As already mentioned, WebDAV server is zimbra briefcase.
  • dstillman
    If you can reproduce this on a test Zimbra installation (if such a thing is possible) and provide me with a login, I can try to reproduce and debug this, but that's about the best I can offer. (A test account on your current server would also work, but if it's a university server that's probably a no-go.)

    As a general rule, we can't debug individual WebDAV servers, since Zotero works fine with properly functioning servers.
  • rtc1
    edited June 13, 2012
    The upload problem itself is definitely on the WebDAV server's side.

    I tried to upload the tmp file directly using curl, and it doesn't work either.

    rtc@...[pts/3](0) ~/.mozilla/firefox/lbucu322.default/zotero/tmp$ curl -vvv -n -T HPE7BZQ8.zip https://rtc@.../dav/rtc@.../Briefcase/HPE7BZQ8.zip
    * About to connect() to ... port 443 (#0)
    * Trying ... ... connected
    * Connected to ... (...) port 443 (#0)
    * successfully set certificate verify locations:
    * CAfile: none
    CApath: /etc/ssl/certs
    * SSLv3, TLS handshake, Client hello (1):
    * SSLv3, TLS handshake, Server hello (2):
    * SSLv3, TLS handshake, CERT (11):
    * SSLv3, TLS handshake, Server key exchange (12):
    * SSLv3, TLS handshake, Server finished (14):
    * SSLv3, TLS handshake, Client key exchange (16):
    * SSLv3, TLS change cipher, Client hello (1):
    * SSLv3, TLS handshake, Finished (20):
    * SSLv3, TLS change cipher, Client hello (1):
    * SSLv3, TLS handshake, Finished (20):
    * SSL connection using DHE-RSA-AES256-SHA
    * Server certificate:

    ...

    > PUT /dav/rtc@.../Briefcase/HPE7BZQ8.zip HTTP/1.1
    > Authorization: ...
    > User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
    > Host: ...
    > Accept: */*
    > Content-Length: 614050
    > Expect: 100-continue
    >
    < HTTP/1.1 100 Continue

    stuck here, but some seconds later:

    * SSLv3, TLS alert, Client hello (1):
    * Empty reply from server
    * Connection #0 to host ... left intact
    curl: (52) Empty reply from server
    * Closing connection #0
    * SSLv3, TLS alert, Client hello (1):

    other files work fine--for them, after "HTTP/1.1 100 Continue", it continues:

    < HTTP/1.1 201 Created
    < Date: Wed, 13 Jun 2012 18:20:44 GMT
    < ETag: "27879-27879"
    < Content-Length: 0
    <
    * Connection #0 to host ... left intact
    * Closing connection #0
    * SSLv3, TLS alert, Client hello (1):

    The file will be on the server in both cases, though.

    I can remove some bytes from the end of the file or add some NUL bytes, and the problem will still occur, though if I create a file completely filled with NUL bytes, of the same length, the problem doesn't occur... But anyway, not a zotero problem.

    Yet, zotero should fail gracefully, with the "Cancel Storage Sync" button working, or even detecting the problem and giving a warning, instead of just spinning the green arrow indefinitely ...
  • dstillman
    What happens if you pass

    -H "Expect:"
    to curl?
    Yet, zotero should fail gracefully, with the "Cancel Storage Sync" button working, or even detecting the problem and giving a warning, instead of just spinning the green arrow indefinitely ...
    I agree—but that might be tough unless we can reproduce it to begin with.
  • dstillman
    Also, is that Content-Length (614050 bytes) correct?
  • rtc1
    edited June 14, 2012
    If I pass '-H "Expect:"' to curl, I get the same result, except that the lines '> Expect: 100-continue' and '< HTTP/1.1 100 Continue' won't be there.

    I can't give you access to the server for the reason you anticipated, it's a university server. But the server software is Zimbra 7.2.0_GA_2669 (build 20120410001957).

    Yes, the Content-Length is correct.
  • rtc1
    We were able to trace the problem on the zimbra WebDAV server side to a degree where we are fairly sure that it has to do with zimbra's indexing system. Zimbra apparently attempts to extract the ZIP file and to pass its contents to an indexer. For said website, the indexer seems to run into problems--the zimbra server log reports I/O errors, probably because of some external indexer program crashing on the ZIP file's contents.
Sign In or Register to comment.