New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interoperability with Gallery2 #7642
Comments
maybe an option under Preferences > Transfers to enable/disable (Expect: 100-continue and Chunked Uploads) . |
The request body is not sent because the server replies with status |
hi David, Thank you for adding a workaround but it's now ending up with duplicate 0-byte files, which can result in 500 Internal Server errors when deleted from within the client itself - I'd have to use a web browser to bypass the errors. I think the ideal solution lies within "headers.remove(HTTP.EXPECT_DIRECTIVE);" that should be controlled in the UI (Preferences > Transfers > General > Uploads, or under Open Connection > More Options) so the user has full control to disable/enable it whenever needed, on demand. When enabled (default) - Cyberduck sends PUT requests with HTTP.EXPECT_DIRECTIVE I am seriously desperate to pay for this option because it will benefit so many (of my) users and resolve this particular PUT request issue. Please advise, and thank you for really taking the time to look into this. here's some excerpt from logs files:
|
You can disable the use of the |
David, Thank you for adding a workaround, even if its not in the UI - at least upload woes are now resolved. Tested on Cyberduck 4.4.x nightly on Mac OS X 10.7.5 - haven't tested the Windows build yet because of some odd handshake failures. As promised, my donation will be coming mid-next week on payday. Will be sending an email to my mailing list so Pixi.me can finally use Cyberduck to upload boatloads of pictures into their Gallery 2 sites. Thanks again! |
Replying to [comment:14 wwwpixime]:
Please note the issue is only resolved when setting the preference. The previously added workaround has been removed as it leads to duplicate files in G2 leading to |
Replying to [comment:14 wwwpixime]:
I suppose these are issues with TLSv1.2 when running on Windows. See #7637. |
looks like 100-continue is appearing where it's not suppose to - PROPFIND requests, the old behavior was only during PUT requests. But even after setting "defaults write ch.sudo.cyberduck webdav.expect-continue false" I'm now seeing this latest snapshot running on Mac OS X 10.7.5 (have "Java 7 update 51" installed)
|
yep, just installed 4.4.3 and defaults write ch.sudo.cyberduck webdav.expect-continue false works as expected. |
Replying to [comment:17 wwwpixime]:
Cyberduck requires no Java installation. |
Replying to [comment:10 wwwpixime]:
Is there a bug filed with Gallery2 to add support for |
hi David, Unfortunately, Gallery2 is no longer in development. It's a solid web based photo management platform (have been using it since 2003), but with a not-so-modern WebDAV implementation. It looks like Cyberduck 4.4.3 with the manual "defaults write ch.sudo.cyberduck webdav.expect-continue false " workaround will do for my users. I'll just let them know not to upgrade to latter versions or their uploads will fail. Thanks again for providing the manual workaround. Sorry to keep pestering about adding a UI option! I'll let this issue lay rest now because it's been too long and you probably have other features to implement far more in demand and important than this. Best regards, |
hi David,
When uploading files to https://g2.pixi.me/w/webdav/ - Cyberduck only render 0-byte files. Finder's built-in WebDAV client and Forklift 2 does the same thing.
I asked a number of the developers who's WebDAV-apps we tested about this issue and was told they use a fallback method when a server fails to respond to an "Expect: 100-continue" request and when chunked uploads are not supported by the server. The fallback method ensures files are properly uploaded, not ending up 0-byte filenames.
If you can shed some light on this, it'd be much appreciated. Even a fix is not an option for Cyberduck, at least I can lay this issue to rest. And will make a donation for pushing to support better, more secure TLS protocols.
Thanks very much!
The text was updated successfully, but these errors were encountered: