The browser therefore drops the response payload and throws the error. And that is what the browser is expecting according to the specs. The crucial point is that this request also runs successfully and returns with status 200 (the payload is also saved to the bucket!) BUT the response does not contain the Access-Control-Allow-Origin header. Then, the actual PUT request gets fired off. You might want to use HTTP toolkit to intercept your browser activity and see what is actually going on with those supposed "CORS" errors.Īccess-control-allow-headers : content-type Turns out, I had a logic issue and was calculating the signature with the incorrect action. Chrome for whatever reason was combining the two requests into a CORS errors which is not the case, very frustrating. The options request was, in fact, returning the right headers, however, the signed request was returning a 403 with a body of Invalid Signature, the signature you calculated is not correct. Since Chrome has taken out OPTIONS requests visibility on chrome 79+, I used a tool called HTTP Toolkit tool to intercept look at exactly what the OPTIONS request was returning. That request would return a CORS error in Chrome devtools stating that dreaded no "ACCESS_CONTROL_ALLOW_METHODS" headers were present. I tried to upload an image with a signed url.
LOCAL CLOUD STORAGE ERROR ORIGIN CODE
That, I believe, is what is happening here, and it is unique to the browser, so isolated nodejs/python/etc code will not reproduce it (since none of those make or validate preflight OPTIONS requests).Īccording to this document:, the server should be returning the Access-Control-Allow-Origin in the OPTIONS response, but it is I dunno if this will help, but I ran into this and spent about 6 hours on it.
If it's in the list, it will proceed with the POST/PUT, if not (or if the header is absent as in this case), it cancels future requests due to the CORS policy. The problem is that the OPTIONS response is not returning Access-Control-Allow-Origin header, which it requires so it can check that the current host is in that list. So, the browser checks to see if it's ok to make a cross origin request, and so issues an OPTIONS request to the bucket on. However, the host there is, which is not. Now, in that website, there is code like you posted above. Restated: you are hosting your website on, which delivers the website payload. If you run that nodejs code from the browser, it will block it due to the preflight OPTIONS request. Uploading and downloading work fine outside of the browser with js, python, and command line. This is only an in-browser issue due to modern browsers' CORS policies. Before it submits the POST request to the signed URL, it submits a preflight OPTIONS request, which does not return Access-Control-Allow-Origin headers, so it abandons the POST request to start the resumable upload. Yet the response still does not return Access-Control-Allow-Origin:
So you can see it is explicitly asking for access-control-allow-origin, content-type headers it specifies origin and also sets sec-fetch-mode to cors. X-client-data: CJO2yQEIo7bJAQisncoBCNCvygEI/K/KAQiesMoBCL2wygEImbLKAQiLtMoBCJa1ygEI7bXKAQiAtsoBCL22ygEIjbrKAQjku8oBCPq7ygEIk73KAQiavcoBGKukygEYy7HKARiks8oBGLW6ygE= I believe I have gone through and checked everything here. Upload from command line using curl works: curl -v -I -X PUT -T file.csv -H 'Content-Type: application/octet-stream', so this appears to be a browser/cors/headers issue. Problem persists on retry, even several hours later. I've also tried adding maxAgeSeconds = 3600, method =, and 'Access-Control-Allow-Origin' to the 'responseHeader' array. It also happens with both the fetch API and Axios npm package. This happens locally, and while hosted on app engine. It looks like the signed URL uses the XML API by default, since the url is /? ( ), which is why I set the CORS above according to the documentation. Response headers include: alt-svc, cache-control, content-length, content-type, date, expires, server, status, vary, x-guploader-uploadid. When this is sent, it runs a preflight OPTIONS request, which does not return the Access-Control-Allow-Origin header in the response, so the PUT fails. 'Content-Type': 'application/octet-stream', # same error with file.type # uploadUri is a signed uri from the 'test' bucket for uploading (PUT requests, v4)
0 kommentar(er)
