We can not access the URL currently. Please download the content and pass it in.

[yamennassif]

When working on the remote label detection i get this message on many (like really many) accessible and existing images. e.g. http://heizung-dinges.de/assets/images/Koebig2.jpg Also some other times i will get the message Bad image data. On different existing and accessible images. Re-requesting the API is not working, same exact errors will occur.

[tcoffee-google]

@yamennassif could you provide more detail about what API and method you are using? Sample code would be helpful to figure out what may be causing the problem.

[yamennassif]

@tcoffee-google i am using the example provided here

https://github.com/GoogleCloudPlatform/java-docs-samples/blob/master/vision/cloud-client/src/main/java/com/example/vision/Detect.java

detectLabelsGcs

with a small change : replaced : ImageSource imgSource = ImageSource.newBuilder().setGcsImageUri(gcsPath).build(); with : ImageSource imgSource =ImageSource.newBuilder().setImageUri(gcsPath).build();

[tcoffee-google]

From https://github.com/GoogleCloudPlatform/google-cloud-node/issues/2215, this appears to be a problem with the backend API, which can be worked around by fetching the image data independently.

The issue has been recently posted on StackOverflow, where it should be picked up by the API team.

[kenyangzj]

Hello any update on this issue?

[drzraf]

Same issue:

• We're not allowed to access the URL on your behalf. Please download the content and pass it in. (code 7)
• We can not access the URL currently. Please download the content and pass it in. (code 4 or 13)

[yamennassif]

@tcoffee-google can you maybe check if there is any updates on this ?

[nitishgargiitd]

Getting this error quite a lot too while using ruby library for Google Cloud Vision

[credi-himanshu]

@nitishgargiitd Were you able to resolve it? If yes, please let me know how.

[ankit-joinwal]

We are also facing this issue . Out of 50 requests, we receive below error for 45 images: We can not access the URL currently. Please download the content and pass it in

Any help is highly appreciated.

[hashwin]

Facing the same issue. The API is not working consistently even though the images should all be publicly accessible.

[tobycheese]

Also getting this now. Same code worked back in September 2017.

[visox]

Same here

{
  "responses": [
    {
      "error": {
        "code": 14,
        "message": "We can not access the URL currently. Please download the content and pass it in."
      }
    }
  ]
}

it did work few days ago :/

[kjj77]

Same error here for a node.js API call :

{ "responses": [ { "error": { "code": 14, "message": "We can not access the URL currently. Please download the content and pass it in." } } ] }

Used to work without problems, it seems to happen randomly on the same image, sometimes the image is processed sometimes this code is returned

[jeffersonlicet]

Any update? Thanks.

[tuanfred]

Any update ? Thanks

[rexhuynh]

We are using gem 'google-cloud-vision' and facing this issue as well. Please update the library

[beccasaurus]

FYI – I've added more information about this error message to a similar issue filed against the Node.js client library for the Cloud Vision API: https://github.com/googleapis/nodejs-vision/issues/270#issuecomment-481064953

[GunnarPDX]

Getting the same error, not sure why though because everything was working fine last week. "We're not allowed to access the URL on your behalf. Please download the content and pass it in."

[joaonew]

Getting the same error, not sure why though because everything was working fine last week. "We're not allowed to access the URL on your behalf. Please download the content and pass it in."

Same here, it was working fine in my project and now all my clientes get this error

[jeffersonlicet]

After talking with Google, here is a list of thing you can do instead:

• Using the Base 64 encoding
• Download the image and storing it in a Cloud Storage Bucket

Good luck.

[GunnarPDX]

Yep, I can confirm that downloading the image in B64 format and using that works and is stable, albeit hurt response times.

[ozturkilgim]

I have the same issue :( I have changed storage rules but it didnt make sense!

[joaonew]

I have the same issue :( I have changed storage rules but it didnt make sense!

And did it work?

[antoniocucc]

I am having the same issue - using the node library and the batchAnnotateImages() function. Any way to fix this other than downloading the images and using a google cloud bucket?

[whoisjuan]

This is still a problem. This API is super unreliable.

[spoorgholi74]

Still and issue we cannot use the image URLs from our S3 bucket with google API.

[eliaweiss]

2020 and this bug is back and BIG!!! What's going on there? can't google handle a simple download action from it's own storage?? This cause my app to be completely broken, and I assume the same for any other app that uses this service, It didn't happen for a year, and since yesterday it happens constantly.

And I don't think that downloading the image and using B64 is a reasonable solution...

Using the gs:// uri is more reasonable, but how do I get this URI from a flutter TaskSnapshot object??

Please solve it ASAP, Please QA your code before uploading it to production... Thanks

[joaonew]

Same here, the problem returned to happen in our App in Production, even tho we are using Google Storage

[benupham]

I get this error repeatedly, and I wonder if it is because the images I am trying to process via URL have a noindex header (they're on a sandbox website of a hosting company that noindexes all websites until they're paid accounts).

[minherz]

hi, i will be glad to help you. can you please elaborate the use case. this repository is a collection of integration examples. it is hard to track the problem without a concrete code excerpt and additional information. the information in previous comments is outdated and often unavailable.

[mdInuvo]

Glad to find this thread. I've got this exact issue in my application. I use Google Vision API and I have images on public https sites and on google cloud storage buckets. Google vision api client can process hundred or thousands images for a few hours and suddenly none of the images can be processed (either on https or on google storage buckets) with this message The URL does not appear to be accessible by us. Please double check or download the content and pass it .. It seemed that I have to restart the application to stop those errors from Google Vision API.

Those failed images are perfectly accessible and if I use the gcUri (or uri out of google storage) of the failed images in google vision api client, it can be processed again.

I check that my quota on vision api is fine. This issue repeatedly happens and I am surprised that this is a known issue for 5 years without a solution. I could load all images to google storage as one of the suggested solutions above, but I confirmed that this error happens for images on google storage buckets.

Please help.

[jontebol]

This bit us as well. Our images are stored on Amazon S3, and switching to Google Storage isn't a viable option.

This means we have to upload the image data thrice, once to our server, then to both S3 and Google vision. If we could use the S3 url, we wouldn't have to send the image data to our server at all, since Google could collect it from S3, and we could upload to S3 directly from the frontend.

[jowo-io]

this is still an issue, happening in my project too. it was working just fine last week, this week: nope.

[jordmax12]

This bit us as well. Our images are stored on Amazon S3, and switching to Google Storage isn't a viable option.

This means we have to upload the image data thrice, once to our server, then to both S3 and Google vision. If we could use the S3 url, we wouldn't have to send the image data to our server at all, since Google could collect it from S3, and we could upload to S3 directly from the frontend.

Just experienced this same issue. This is definitely not a bug and on purpose Google made it so you cant use s3 url's even if they are signed or publicly accessible. This is a huge issue for us as we dont want to have to download the image from s3 and convert to base64. We use AWS Lambdas and could have a batch size of 100, so I really do not want to have to download that for each record, or worse decrease the batch size just for a simple logo detection.

I doubt you're still having this issue, but for anyone who is, I highly recommend Azure instead as the logo detection is much better and also works with s3 signed urls. I have zero affiliation with Azure btw, I dont work there never have and never will. I strongly dislike Azure for everything other than their computer vision suite of products.

Google you guys are absolutely awful for limiting your service this way. There's no way this is on accident as this was opened in 2017. Its now 2024. The same s3 signed url works on azure and any other logo detection service I looked into, the only one that did not work was Google Cloud Vision. So ironic the company slogan is "do no evil", you guys are the epitome of evil tech companies. Making your service worse on purpose for users who are paying money is definitely evil.

[drzraf]

There's no way this is on accident as this was opened in 2017. Its now 2024. The same s3 signed url works on azure and any other logo detection service I looked into, the only one that did not work was Google Cloud Vision. [...] Making your service worse on purpose for users who are paying money is definitely evil.

I found them dropping packets (to googleapis, eg: oauth) when accessed from specific (competing) hosting provider, messing with SSL over IPv6 from specific (competing) datacenter, and doing all sorts of subtle (and less subtle) things at the network/network-quality level to maintain monopoly and supremacy.

Nowadays they even attack Europeans VPN providers and segment the internet using reCaptcha (hand in hand with Cloudflare) and so on and so on...

If only it was just about GoogleVision API 🤣 ! (Looking at the rear-view, the situation was much better back in 2017) NB: The "do not evil" moto is long gone (but was actually a smart trick to bootstrap in the early 2000')