Skip to content
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

Bad request (interoperability failure) #11062

Closed
cyberduck opened this issue May 31, 2020 · 9 comments
Closed

Bad request (interoperability failure) #11062

cyberduck opened this issue May 31, 2020 · 9 comments

Comments

@cyberduck
Copy link
Collaborator

@cyberduck cyberduck commented May 31, 2020

25e1c83 created the issue

Hi there,

I am using Cyberduck on Windows 10 version 2004.

I recently upgraded Cyberduck from version 7.2.7 to 7.4.1 and noticed that I can no longer upload files to Google Cloud Storage using the Google Cloud Storage OAuth method. The error I am getting is an "interoperability error", as shown in the attached screenshot.

I went back to test verisons 7.4.0, 7.3.1 and 7.3.0 and noted that the issue seems to happen beginning with 7.3.1. On version 7.3.0, I have no issues with uploading files to Google Cloud Storage.

I have made sure to remove credentials and remove all saved settings/ files relating to Cyberduck but I still get the same issue.

Currently, my workaround is to use S3 interoperability mode to upload files to Google Cloud Storage. However, it would be good if the native option could be fixed.


Attachments

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Jun 5, 2020

@dkocher commented

We cannot reproduce this. Reviewed test in 31abd0c.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Jun 5, 2020

25e1c83 commented

I am still having the same issue. Is there any way to share my logs or something? If it helps, I noticed this only happens when I upload a new file. If I am overwriting an existing file, there is no issue.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Jun 17, 2020

25e1c83 commented

Hi there,

Just wondering if there would be any way to fix this in the near future? I have downloaded the latest 7.4.1 stable release which does not fix the issue.

I was looking through the repository here: https://trac.cyberduck.io/browser/trunk/googlestorage/src/main/java/ch/cyberduck/core/googlestorage?rev=49350&order=date&desc=1 and noted there were changes made on April 21st which coincided with the period between 7.3.0 and 7.3.1. So I think the bug could have been introduced during this stage. The nightlies for immediately before April 21st is no longer available so I cannot confirm this. However, I downloaded the nightly on April 29th (before the additional amendments made on April 30th) and noted the same issue, so I am guessing the April 21st change introduced this bug.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Jul 10, 2020

afb2c2c commented

I am experiencing the exact same issue here on both the windows and the mac clients.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Jul 14, 2020

afb2c2c commented

Replying to [comment:1 dkocher]:

We cannot reproduce this. Reviewed test in 31abd0c.

I have now debugged this issue. As part of the upload request, the parameter "storageClass": "multi_regional" is being sent.
This parameter is deprecated and will only work for multi regional buckets. Unless Cyberduck is to add support for setting the storage class in preferences, then I suggest the parameter is removed. This will then use the default storage class of the bucket.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Jul 15, 2020

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Jul 16, 2020

@dkocher commented

In e35f47c.

@cyberduck cyberduck closed this Jul 16, 2020
@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Nov 8, 2020

25e1c83 commented

Hi there,

Sorry to dig this up -- let me know if I should be creating a new ticket instead.

I noticed with the latest fix, the interoperability failure is fixed. However, Cyberduck will no longer honour the default storage class setting and will always upload files with storage class "Standard". As my storage bucket is using the "Archive" storage class (which, incidentally, does not appear to be supported by Cyberduck at the current moment in the "Info" tab), I have to change them manually using gsutils after each upload.

I wonder if it is possible to avoid specifying the "storageClass" parameter altogether, as per what itspage suggested, such that the file will upload only to the default storage class setting?

Thank you.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Jan 3, 2021

@dkocher commented

Replying to [comment:10 trenzterra]:

Hi there,

Sorry to dig this up -- let me know if I should be creating a new ticket instead.

I noticed with the latest fix, the interoperability failure is fixed. However, Cyberduck will no longer honour the default storage class setting and will always upload files with storage class "Standard". As my storage bucket is using the "Archive" storage class (which, incidentally, does not appear to be supported by Cyberduck at the current moment in the "Info" tab), I have to change them manually using gsutils after each upload.

I wonder if it is possible to avoid specifying the "storageClass" parameter altogether, as per what itspage suggested, such that the file will upload only to the default storage class setting?

Thank you.

In #11521.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 27, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants