I have been able to run several jobs on Forge, but I am running into a new situation today. It seems like the workitem stays idle for about 70 minutes even when it reports back "In Progress". Finally when the workitem starts, it fails immediately on downloading resources. I am assuming because the signed URL doesn't last that long:
[06/10/2022 01:07:09] Starting work item accb10182b02420f925ccd4d113dffbd
[06/10/2022 01:07:09] Start download phase.
[06/10/2022 01:07:09] Start downloading input: verb - 'GET', url - 'https://developer.api.autodesk.com/oss/v2/signedresources/b70c5565-0ff5-48cb-af7b-b3f57113786e?region=US'
[06/10/2022 01:07:10] Embedded resource [{"ViewName": "VR_EXPORT"}] is saved as file: T:\Aces\Jobs\accb10182b02420f925ccd4d113dffbd\params.json.
[06/10/2022 01:07:10] Error: Failed - 404 (Not Found)
Request: GET https://developer.api.autodesk.com/oss/v2/signedresources/b70c5565-0ff5-48cb-af7b-b3f57113786e?region=US
Response Headers:
Access-Control-Allow-Headers: Authorization, Accept-Encoding, Range, Content-Type
Access-Control-Allow-Methods: GET
Access-Control-Allow-Origin: *
Date: Fri, 10 Jun 2022 01:07:10 GMT
Strict-Transport-Security: max-age=31536000; includeSubDomains
x-ads-region: US
X-Content-Type-Options: nosniff
Connection: keep-alive
Response Content Headers:
Content-Type: application/json; charset=utf-8
Content-Length: 38
Response Body:
{"reason":"Signed Resource not found"}
Not sure if this is an internal issue with Design Automation or I am doing something wrong.
Related
I recently set up a content delivery network for mp3 files (spoken word podcast stuff) with Microsoft Azure. At first everything worked fine, but recently the files started "skipping", i.e. resetting themselves. For example when the player reached the 3:30 mark of the file it would go back to the 0:15 mark of the file. For some reason this is only happening when serving the files under https, not under http
Specifics:
It is only happening on Chrome - I've tested under Edge and Firefox too - they work perfectly
It happens across multiple computers
Only the https version of the file has the problem, the http version is fine
It works using the plain vanilla audio tag - no fancy player involved
When this happens there is no entry in the console in the dev tools, nor a new download in the media window
I uploaded the same file to Amazon S3 - put it in the same plain vanilla player and it plays just fine under https.
How can this be happening?
Headers from the NOT working request from Azure
Request Method: GET
Status Code: 206 Partial Content (from disk cache)
Referrer Policy: no-referrer-when-downgrade
Accept-Ranges: bytes
Access-Control-Allow-Origin: *;
Access-Control-Expose-Headers: x-ms-request-id;
Content-Disposition: attachment; filename=XXXXXXXXXXX.mp3;
Content-Length: 76434500;
Content-Range: bytes 0-76434499/76434500;
Content-Type: audio/mpeg;audio/mpeg3;;
Date: Mon;
ETag: "0x8D5EC5B899726B0";
Last-Modified: Wed;
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0;
status: 206;
x-ms-blob-type: BlockBlob;
x-ms-lease-state: available;
x-ms-lease-status: unlocked;
X-MS-Ref: 0DGxVWwAAAAA2BOMWL9GzRqSzc9yi5SF4QkwyRURHRTA1MTIAMzc1ZmRlZDMtMjA3My00Y2YxLTljZGMtNzc4NGMxYmI3ZmZi;
x-ms-request-id: 998f9297-301e-00bc-2945-22fa9f000000;
x-ms-version: 2014-02-14;
Headers from the working request from Azure
Request Method: GET;
Status Code: 206 Partial Content (from disk cache);
Remote Address: 52.239.152.234:80;
Referrer Policy: no-referrer-when-downgrade;
Accept-Ranges: bytes;
Access-Control-Allow-Origin: *;
Access-Control-Expose-Headers: x-ms-request-id;
Content-Disposition: attachment; filename=XXXXXXXXXXX.mp3;
Content-Length: 76434500;
Content-Range: bytes 0-76434499/76434500;
Content-Type: audio/mpeg;audio/mpeg3;;
Date: Mon;
ETag: "0x8D5EC5B899726B0";
Last-Modified: Wed;
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0;
x-ms-blob-type: BlockBlob;
x-ms-lease-state: available;
x-ms-lease-status: unlocked;
x-ms-request-id: 6246c264-401e-017b-1b47-22c00b000000;
x-ms-version: 2014-02-14;
Headers from the working request from S3
Accept-Ranges: bytes;
Content-Length: 76303428;
Content-Range: bytes 131072-76434499/76434500;
Content-Type: audio/mp3;
Date: Mon;
ETag: "09fac410597469e6db237376a0e2505d-5";
Last-Modified: Sun;
Server: AmazonS3;
x-amz-id-2: ictUYlZjFNJwa2g8q09TowZuc3quHiHmZsYmq7b/hjIgEsoIKpZIYrlqBCea1NYScr9QukHPqZY=;
x-amz-request-id: 6FE8390CF92213AF;
I am trying to inspect an HTTP request made in my browser with the chrome dev tools. I want to see the response but it seems to be empty (failed to load data), whereas the Content-Type is set to 4464326.
Below the HTTP response headers :
HTTP/1.1 200 OK
Last-Modified: Tue, 21 Jan 2014 12:08:30 GMT
ETag: "3ba731138c01f1ad6536bc1d4030cfdd"
Content-Type: audio/mpeg
Server: AmazonS3
Content-Length: 4464326
Accept-Ranges: bytes
Date: Wed, 04 May 2016 13:02:20 GMT
Via: 1.1 varnish
Age: 153069
Connection: keep-alive
Cache-Control: no-cache, no-store, private
X-Served-By: cache-fra1226-FRA
X-Cache: HIT
X-Cache-Hits: 2
X-Timer: S1462366940.863431,VS0,VE0
Plus, in the timeline, I see a download time of 4.61s so I guess to response was not actually empty.
I also tried with Fiddler but responser is still unavailable. Does someone has an explanation, or even better, knows how I can try to read the response ?
As you can see,
Content-Type: audio/mpeg
Can the chrome dev tools read this type of content?
When you are streaming a video, the Response panel shows as empty because the request hasn't completed yet. Once completed, it displays "Failed to load response data", since the data is likely to be too large to display as text in the panel.
You could try Wireshark to capture the HTTP response data.
I'm experiencing an issue with Chrome that I can't seem to fully understand, I'm curious if folks here have dealt with it before. This doesn't reproduce in Firefox. The steps are as follows:
Start incognito Chrome, navigate to https://foo.mysite.com and have the JS on the page make a GET ajax request to S3 for https://s3.amazonaws.com/mystuff/file.json . You get back a 200 response with:
HTTP/1.1 200 OK
x-amz-id-2: somestuffhere
x-amz-request-id: somestuffhere
Date: Tue, 14 Oct 2014 03:06:41 GMT
Access-Control-Allow-Origin: https://foo.mysite.com
Access-Control-Allow-Methods: GET
Access-Control-Max-Age: 3000
Access-Control-Allow-Credentials: true
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
Cache-Control: max-age=86400
Content-Encoding: gzip
Last-Modified: Sun, 05 Oct 2014 00:29:53 GMT
ETag: "fe76607baa40a793eb3b3cbd373a3fb8"
Accept-Ranges: bytes
Content-Type: application/json
Content-Length: 5609
Server: AmazonS3
Open a second tab, navigate to https://bar.mysite.com and have its JS make a GET ajax request to S3 for the same file https://s3.amazonaws.com/mystuff/file.json . Get back the following 304 response:
HTTP/1.1 304 Not Modified
x-amz-id-2: somestuffhere
x-amz-request-id: somestuffhere
Date: Tue, 14 Oct 2014 03:06:58 GMT
Access-Control-Allow-Origin: https://bar.mysite.com
Access-Control-Allow-Methods: GET
Access-Control-Max-Age: 3000
Access-Control-Allow-Credentials: true
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
Cache-Control: max-age=86400
Last-Modified: Sun, 05 Oct 2014 00:29:53 GMT
ETag: "fe76607baa40a793eb3b3cbd373a3fb8"
Server: AmazonS3
Open a third tab, navigate to https://foo.mysite.com (the first site) and repeat the same steps as in 1. Chrome kills the response for CORS reasons and reports the following:
XMLHttpRequest cannot load https://s3.amazonaws.com/mystuff/file.json. The 'Access-Control-Allow-Origin' header has a value 'https://bar.mysite.com' that is not equal to the supplied origin. Origin 'https://foo.mysite.com' is therefore not allowed access.
What's the story here? This doesn't reproduce in Firefox. In Firefox I'm happily getting a 304 in both steps 2 and 3, which I would expect to see in Chrome as well.
A temporary workaround for this issue in Chrome is to set Cache-Control: no-cache on the file in S3, but then I'm forcing our clients to be re-downloading that file for no good reason, so it's not a real solution.
Is this intended and documented behavior? Is this a bug with Chrome? Any other thoughts?
Looks like this is caused by Chromium issue 260239
I found this blog that help: Add Vary headers to S3
It helped by adding Vary headers to all XHR request.
I did run into a problem with html request (i.e. ) but I was able to overcome that by using hackround#2 described here:https://serverfault.com/a/856948
TL;DR of hack#2 is to use a "dummy" query string parameter that differs for HTML and XHR or is absent from one or the other. Example:
<img src="https://s3.png?x-request=html">
I just add a timestamp in request URL to force load the asset from S3 again, not from cache, such as xxxx?timestamp=yyyy
we have several google oauth2 refresh tokens for Google Drive for which we always get the following error when trying to request a new access token:
POST /o/oauth2/token HTTP/1.1
Connection: close
accept-encoding: gzip, deflate
content-type: application/x-www-form-urlencoded
Content-Length: 208
Host: accounts.google.com
refresh_token=1%2FY5_2XY8uGujYa222rxXnsjR<snipped>&client_id=<clientid>&grant_type=refresh_token&client_secret=<clientsecret>
Response:
HTTP/1.1 400 Error processing OAuth 2 request
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Date: Tue, 20 Aug 2013 14:55:24 GMT
<HTML>
<HEAD>
<TITLE>Error processing OAuth 2 request</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
<H1>Error processing OAuth 2 request</H1>
<H2>Error 400</H2>
</BODY>
</HTML>
This only happens for some accounts, others work fine. The broken accounts fail reproducibly across days and weeks. Is there something wrong with the data we send? Any hint on what fails the validation?
I could provide you the tokens that are failing if necessary.
As far as I can tell all these refresh tokens fail because of invalid user accounts (deleted, disabled, etc). In these cases for all intents and purposes the token itself is invalid.
The HTML error response is a bug, and it should be fixed by now. Please report if you still see errors like this. The proper OAuth 2 error code in this case is "invalid_token".
Suddenly, I am getting an error during the Oauth process, after my app has been given permission for access by the user and a authorization code is delivered to my redirect url. I've been using the same code for a couple weeks now, and it has been working fine. I'm pretty certain I haven't made any changes.
Is there an issue with Google Drive API today?
The error occurs here in Python code here:
credentials = flow.step2_exchange(authorization_code)
Error message:
FlowExchangeError: Invalid response 400.
The entire exchange_code method as copied from Google example:
def exchange_code(authorization_code):
"""Exchange an authorization code for OAuth 2.0 credentials.
Args:
authorization_code: Authorization code to exchange for OAuth 2.0
credentials.
Returns:
oauth2client.client.OAuth2Credentials instance.
Raises:
CodeExchangeException: an error occurred.
"""
logging.debug(authorization_code);
flow = flow_from_clientsecrets(CLIENTSECRETS_LOCATION, ' '.join(SCOPES))
flow.redirect_uri = REDIRECT_URI
try:
credentials = flow.step2_exchange(authorization_code)
return credentials
except FlowExchangeError, error:
logging.error('An error occurred: %s', error)
raise CodeExchangeException(None)
Using Oauth Playground, I get the following error response:
HTTP/1.1 400 Ok
Status: 400
Content-length: 37
X-xss-protection: 1; mode=block
X-content-type-options: nosniff
X-google-cache-control: remote-fetch
-content-encoding: gzip
Server: GSE
Via: HTTP/1.1 GWA
Pragma: no-cache
Cache-control: no-cache, no-store, max-age=0, must-revalidate
Date: Fri, 10 Aug 2012 03:23:54 GMT
X-frame-options: SAMEORIGIN
Content-type: application/json
Expires: Fri, 01 Jan 1990 00:00:00 GMT
{
"error" : "unauthorized_client"
}
Any ideas why this would start happening when the code was working for weeks as it is now?
Thanks,
Chris
The HTTP response code 400 means that your request is somehow invalid and there should be a more descriptive error message telling you what is wrong.
Perhaps the Python library is hiding the complete message, I'd recommend you to try the same request with the OAuth 2.0 Playground and compare it with yours:
https://code.google.com/oauthplayground/
I was finally able to get the code working again. I reverted the GAE app version to my prior version. Oauth exchange_code worked again. Then I took it back to the current version on GAE, with no changes to the code whatsoever, and it continues to work.
So the oauth process did stop working when I recently created new version in GAE with no changes to the code. For what it's worth.....