When I import a large mail filer via ews-managed api, it encountered http code 500 with reponse:
Cache-Control: private^M
Content-Length: 1015^M
Content-Type: text/xml; charset=utf-8^M
Date: Thu, 20 Sep 2018 03:03:01 GMT^M
HTTP/1.1 500 Internal Server Error^M
Server: Microsoft-IIS/10.0^M
Set-Cookie: exchangecookie=12133ae873f24a8f80b93e5b92ab3979;
expires=Fri, 20-Sep-2019 03:01:27 GMT; path=/; HttpOnly^M
X-AspNet-Version: 4.0.30319^M
X-BEServer: PS2PR02MB2694^M
X-BackEndHttpStatus: 500^M
X-BeSku: WCS5^M
X-CalculatedBETarget: PS2PR02MB2694.apcprd02.prod.outlook.com^M
X-CalculatedFETarget: PS2P216CU002.internal.outlook.com^M
X-DiagInfo: PS2PR02MB2694^M
X-FEProxyInfo: PS2P216CA0031.KORP216.PROD.OUTLOOK.COM^M
X-FEServer: HK0PR03CA0085^M
X-FEServer: PS2P216CA0031^M
X-Powered-By: ASP.NET
X-RUM-Validated: 1
request-id: 905db567-dcf7-449c-820d-b00ed0afa981
x-ms-appId: af08ce07-1df9-4a39-b6e6-092ac934eb21
However, the mail was successfully uploaded.
It should be a mismatch error code, or something wrong in this request.
Should I retry this request again? or anyway to improve this behavior?
Thanks for help.
Make sure your setting the X-AnchorMailbox header to the Mailbox your importing to otherwise the backend servers will be proxying the request on you behalf so you can get that type of error for long running operations when the server doesn't receive the response in time (the state of the operation at that point is unknown).
Related
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.
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 am trying to use http://manifest-validator.com/ to check my cache manifest file by URI. It has been failing with the message:
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST /validate.
Reason: Error reading from remote server
I have tried removing my robots.txt file in case Disallow: / was causing problems.
Has anyone else experienced this Proxy Error?
Is this something that I can fix or is it an error with manifest-validator.com ?
In short
The reason for your error in this validator is a missing content-type attribute in your http response headers. Add one like text/cache-manifest and it will work.
Explaining the details
First of all, here are the response headers sent by your server. Note the missing content-type:
robert#robert-ubuntu:~$ curl -I -X HEAD http://nucreativetesting.co.uk/cache-test/test003/manifest.appcache
HTTP/1.1 200 OK
Date: Tue, 07 Oct 2014 16:25:59 GMT
Server: Apache/2.4.9 (Unix)
Last-Modified: Mon, 11 Aug 2014 13:45:07 GMT
ETag: "46c-5005ac34a2331"
Accept-Ranges: bytes
Content-Length: 1132
Why the proxy error?
The validator you are using is a NodeJS project, proxied by an apache webserver. The reason you get an error is that the apache waits for NodeJS to generate a response but it's hanging. After some time it gets a timeout and returns your error.
So why is it hanging?
In the current implementation of this validator you find the following code [1]:
try {
contentType = res.headers['content-type'].split(';')[0];
if ( ['text/plain', 'text/cache-manifest'].indexOf( contentType ) === -1 ) {
callback('ERR_MANIFEST_MIMETYPE');
return;
}
} catch(e) {
// TODO: Debug statement in production, had some strange output in the error logs.
// Should be removed again
console.error('manifest.js: Content-Type');
return;
}
We see that res.headers['content-type'] should get split, but if there's no content type in your request header, this will raise an Exception because res.headers['content-type'] is undefined. The Exception itself is just logged to the servers output but isn't handled with their callback() function. Thats the reason the request is hanging till timeout.
Conclusion
It might be a bug or bad error handling on their side or just very unusual to not have a content type in your header. I don't know. But it should work with a content type ;).
References
[1]: https://github.com/fhemberger/manifest-validator/blob/6d82bc4660c4daaa131fee3c19a88ae6e462a44b/app/lib/manifest.js#L63 code producing your error
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.....