I'm getting this error message (100% of the time) when copying a shared file, using the latest version of php library. And I'm getting the same response via the API explorer: developers.google.com/drive/v2/reference/files/copy
Google_Exception: Error calling POST
https://www.googleapis.com/drive/v2/files/#fileid#/copy: (500) {
"error": { "code": 500, "message": null } }
This issue seem to just appear since 3am, 4th Jun 2015 (from Google dev console) and only happening to large files (~1GB). Those files are now showing "Google Drive can't scan this file for viruses." when trying to download it. Google decreased maximum size that it can scan? Is theres any flags like "acknowledgeAbuse" for copy method?
Screenshot API Console:
Possible duplicate but unfortunately not answered (as of now): Google Drive SDK 500 errors on copy
This error was due to a bug in the Drive API. Here's the canonical issue report:
https://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=3862
In the future please file issues there instead of posting on Stack Overflow.
The bug should now be fixed.
Related
I am trying to download content of a previous revision of a file using the google drive api for Ruby Google::Apis::DriveV3::DriveService#get_revision:
Tempfile.create('file_revision-', encoding: 'ASCII-8BIT') do |temp_file|
drive_api_service.get_revision(file_id, revision_id, download_dest: temp_file)
# work with the content
end
I keep getting Google::Apis::ClientError with status code 403, reason phrase "Forbidden". The scope https://www.googleapis.com/auth/drive is enabled and the error occurs only when I am trying to download the content of the revision. If I run the code without the parameter download_dest, the request succeeds without any problems. I am also able to fetch any meta data or revision, export files, upload files etc., the problem only occurs when I try to fetch the content, either by get_file or get_revision.
Has anyone encountered this issue?
Is there an additional permissions that specifically needs to be added to allow content downloading?
I have also looked at other questions on stack overflow and I have checked all possible configuration for google drive api I could find and everything seems to be enabled.
Right now, Google drive api does not support content downloading for native google drive files (google docs, sheets etc.), so you cant download content (current or of an old revision), you can only export it to a different mime type.
Recently, one of our client reports that he cannot backup files in his Team Drive using our app. We will be thankful if someone can help us figure out why.
We use alt=media method to download file. That is, https://www.googleapis.com/drive/v3/files/[FILE_ID]?alt=media. Reference link here. It works perfectly for most of the files on client side.
However, if we download some of files using this method, we got the following response from Google:
{
"error": {
"code": 500,
"message": null
}
}
These files are in Team Drive and with various extensions (not online doc). For example, .xlsx, .pdf, .jpg, etc. We re-tried few days and ALWAYS got this response message (500 with null message). We cannot get this working even if we append &supportsTeamDrives=true at the end of the URL.
By checking with GET file API, this file DOES exist on Google Drive. Even more surprisingly, we CAN DOWNLOAD this file using the URL provided in downloadUrl field from file resource! How could this happen?
We cannot find more information from Google's API document about this phenomenon. Please help us if someone knows why.
Thank you!
UPDATED:
We got the latest information from our client. It seems that these files are under some folders which are migrated from My Drive to Team Drive. Also, the creation time of these folders are ranging from 2014 to 2016, which are before the official Team Drive early adoption program.
We don't know if these facts are related to the download problem or not, since not all files under these folders are problematic. Only some of these files cannot download through alt=media method.
My goal: I'd like to use an image from commons.mediawiki.org within a MediaWiki installation.
First I was trying to debug my InstantCommons configuration: Referring to files on commons.mediawiki.org failed for some reason. After activating various debugging options I learned that though general image download succeeded some kind of thumbnail followup request issued by the MediaWiki installation failed, which resulted into an overall error from the ForeignAPIRepo-Module.
As I can not deal with this error right now I thought I'd try something else as some kind of fallback: Download the MediaWiki image by specifiying the image URL in the upload image web page. The idea is to let MediaWiki download the image and include this image as regular wiki content. This way I would require to add license details manually and add a few comments, but this would be better than having no image.
But trying this I strangely get an error: It says "Fehler beim Senden der Anfrage" which means "Error while sending the request". But the internal request seems succeed in the logs. Here is what MediaWiki was logging:
[fileupload] Temporary file created "/tmp/URLdafce5345aa3-1"
[fileupload] Starting download from "https://upload.wikimedia.org/wikipedia/commons/c/c7/Broccoli%2C_Champignons%2C_Karotten_%2810581663524%29.jpg" <followRedirects>
[fileupload] <Error, collected 1 error(s) on the way, integer value set>
+------+---------------------------+------------------------------------------+
| 1 | http-request-error | |
+------+---------------------------+------------------------------------------+
[fileupload] Download by URL completed with HTTP status 200
Comment: All other log messages do not indicate anything that looks like an error or is related to the task of downloading the image, so I skipped them here.
The URL is correct, the image can be downloaded from the URL, MediaWiki receives a response code of 200, but instead of processing the response it indicates an error. Why? For http and https URLs I get the same result in the log.
Has anybody encountered this problem before in MediaWiki installations? Does anyone have any idea what the reason for this behaviour could be?
Comment: The wiki is of version 1.25.2 and a standard installation including SWM on an up to date standard Ubuntu Linux OS. Nothing exotic, nothing modified in any way.
Comment: Yes, I could upgrade to the latest version but, I'm not sure if this really solves the problem: I know that this featured did work in some other MediaWiki installations I have set up some time ago. Does anyone have a clue why this feature could fail here? Has anyone encountered something like this before?
Edit: I experimented with downloading from another MediaWiki instance of exactly the same version - 1.25.2 - in my local network. This did not succeed as well. But I get a different error message (translated): "The file .... could not be stored at ...". The "funny part": Though the error message indicated otherwise the file has been downloaded successfully and stored as expected. It has the correct user rights as one would expect, but log messages indicate that there are bugs in MediaWiki regarding this part: ("PHP Notice: Undefined property: UploadFromUrl::$nbytes") Maybe the uploading implementation is buggy somehow and the problems I am running into are typical?
There are multiple bugs with HTTPS support in MediaWiki, php-curl etc. See https://www.mediawiki.org/wiki/InstantCommons#HTTPS for debugging information, there is no magic bullet.
I have a project which now doesn't work when I download binarie from onedrive like PNG. I got a bad request in query response. I take some backup and they have the same problem. This was working few days ago I have not modify anything. Is there a changne in the api ? I download xml with no problem whith same query.
I try to test apigee console and it seems to work. Anyone has same problem ? Got solution ?
THANKS a lot
I go this response from api :
StatusCode: 400, ReasonPhrase: 'Bad Request'
For those that find their way here, the problem in question is a result of some proxy servers rejecting the URLs when they contain single path segments with more than 260 characters. Unfortunately this is possible with the URLs that the OneDrive API generates, and so we're investigating changes to resolve this kind of problem.
The issue can be tracked at https://github.com/OneDrive/onedrive-api-docs/issues/143
Generally, I don't ask questions to stackoverflow because I always find an answer by searching. But today, we have a very important problem.
We have somes Drive API issues for a few hours.
A lot of 500 Internal Server Error when we want to take the ownership of a document.
We have tested directly with APIs Playground and it's the same :
https://developers.google.com/drive/v2/reference/permissions/insert
{
"role": "owner",
"type": "user",
"value": "blabla#example.com"
}
The big problem is the API return an error but the take ownership is OK. So Google return to us an error whereas the request is passed correctly...
Does it means we can't trust the API ?
We use Python for this application but we have the same issue for the same request in another application in Java...
Drive is having one of its bad hair weeks. They happen from time to time.
To answer "Does it means we can't trust the API ?", well trust is a bit subjective, but we have started to add defensive coding to our apps. So rather than assume the API is working to spec, we assume it isn't and do a double check.
Eg.after an insert we are now re-fetching the inserted file to confirm that it has been correctly inserted. We also track 304 rate limit errors on inserts because sometimes, despite the exception, the file was inserted. (similar to your observation, except you're seeing 500).