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
Related
I'm trying to debug a call made from a Java desktop application to a Java server, which goes via Apache http server. The call is an http json call, I want to log the request and response on Apache. I have enabled the dump io module and can now see the request and response, but the response is formatted as binary:
16:58:10 GMT\r\nX-XSS-Protection: 1; mode=block\r\nX-Content-Type-Options:
nosniff\r\nReferrer-Policy: no-referrer\r\nbreadcrumbId: ID-machine-name-here-33747-
1626280202382-10-673\r\nContent-Type: application/json;charset=UTF-8\r\nSet-Cookie:
JSESSIONID=88F411906EC0D; Path=/; HttpOnly\r\nVary: Accept-Encoding\r\nContent-
Encoding: gzip\r\nSet-Cookie: ROUTEID=.1; path=/app-path\r\nContent-Length:
61\r\nConnection: close\r\n\r\n
[Fri Jul 16 17:58:07 2021] [debug] mod_dumpio.c(74): mod_dumpio: dumpio_out (data-
HEAP): \xabV\xaa\xc8\xcdQ\xb2R\xb2)JMK-
J\xcdKNuI,I\x0cIL\xcaIuIM\xcb\xcc\xcb,\xc9\xcc\xcf\xd3\xb7S\xaa\x05
Why is this showing as binary? Is there a way I can get this logged as text?
Why is this showing as binary?
Everything is binary, but the reason it's not showing as plain text is because this is the actual body that's sent, and the body is gzipped.
Is there a way I can get this logged as text?
You could turn off gzipping.
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).
POST https://api.smtp2go.com/v3/stats/email_summary HTTP/1.1
Host: api.smtp2go.com
Content-Type: application/json
Connection: close
Content-Length: 52
{ "api_key":"api-" }
GETTING response as
400 Bad Request
Bad Request Your browser sent a request that this server could not understand. Apache/2.4.10 (Debian) Server at us-api-1.smtp2go.com Port 80
For security reasons, you should not post your API Key publicly. I would recommend removing it from this post. As for your problem, I would recommend that you double check that your API key is active. That could be part of the problem.
If that is not your problem. I'd recommend checking out this site which includes all API error codes. https://kb.insideview.com/hc/en-us/articles/202959833-API-Error-Codes
I'm new to this with a very low background so bear with me. I want to debug my issue of prematurely terminating loading the page from the reverse proxied site as it request something like filename.json file. I noticed in the request header it has Content-Type:application/x-www-form-urlencoded, and the response headers are
$WSEP:
Cache-Control:no-cache
Connection:Keep-Alive
Content-Encoding:gzip
Content-Language:en-US
Content-Length:55
Content-Type:text/html;charset=UTF-8
Date:Sun, 12 Jun 2016 04:54:18 GMT
Expires:Thu, 01 Jan 1970 00:00:00 GMT
Keep-Alive:timeout=5, max=97
Server:Apache
Vary:Accept-Encoding
X-Cnection:Close
but I'm wondering why it's text/html content-type when it's json, so I tried manipulating the response with application/json and even trying to instead of downloading the page from the remote server, I made it download locally from my server /var/www/html by creating dummy json file. I was thinking because this is json file it should be application/json not text/html as Content-Type. But the issue still exists. It just stops when it reached requesting that json file.
Now my question is, how can I make sure that requesting to that json is the culprit? Or more appropriately, how can I debug the mod_perl. I tried adding
use warning;
in the code
PerlWarn On
in the apache config but still I don't see any warning/errors that will guide me to debug.
Can you give me advice on how to do find the fault?
By the way, the site of that json file being requested returns 404 but I assume that the proxy server should ignore it and continue downloading other files.
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.....