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
Related
I have a page served via HTTPS. All content is public and no sensitive data is on this page. I also have resources (audio mp3) on a google cloud bucket which has no HTTPS support and is a subdomain (DNS C-NAME entry only), but is reachable via HTTPS but returns a Google certificate if accessed by https. Until now I had my server respond with a 302 redirect to my subdomain downgrading static mp3-resources from HTTPS to HTTP and it worked. See this request:
Request:
Request URL: https://x.com/q/ics/edit/r.6c19e2d99e220f648b3c1799ed05dc99.mp3
Request Method: GET
Status Code: 302
Remote Address: 172.217.19.115:443
Referrer Policy: no-referrer-when-downgrade
Response:
content-length: 259
content-type: text/html; charset=UTF-8
date: Wed, 24 Jun 2020 05:42:46 GMT
location: http://subdomain.x.com/ics/_resources/r.6c19e2d99e220f648b3c1799ed05dc99.mp3
server: Google Frontend
status: 302
x-cloud-trace-context: 3086726898e017b2b99858fcea43c5e0
But suddenly Chrome started ignoring location: http: and instead resolves the HTTPS version, which causes ERR_CERT_COMMON_NAME_INVALID and this fails the download.
I know this can be resolved by using a load-balancer, but that would almost double our hosting costs (maintenance/setup/learning costs not included!) and we really do not need a load balancer with AppEngine classic.
The problem occurred a few weeks ago the first time, but went away within a day, but is persistent now!
Does anyone know why Chrome is interpreting the redirect this way? Is this required by any specification?
Update: The only solution I found so far is to downgrade the whole page with a redirect from HTTPS to HTTP. That is really a sad solution.
I'm trying to set up HAProxy to server a static JSON file on 504 errors. To test, we've set up the configuration file to timeout after 10 seconds, and to use the errorfile option:
defaults
log global
mode http
retries 3
timeout client 10s
timeout connect 10s
timeout server 10s
option tcplog
balance roundrobin
frontend https
maxconn 2000
bind 0.0.0.0:9000
errorfile 504 /home/user1/test/error.json
acl employee-api-service path_reg /employee/api.*
use_backend servers-employee-api if employee-api-service
backend servers-employee-api
server www.server.com 127.0.0.1:8000
Effectively, I'm trying to serve JSON instead of HTML on a timeout, so the backend service can fail gracefully. However, on testing, we could not get anything, neither HTML or JSON. On looking at the response, it simply says it failed, with no status code. Is my setup correct for errorfile? Does HAProxy 1.5 support this?
According to the documentation of errorfile:
<file> designates a file containing the full HTTP response. It is
recommended to follow the common practice of appending ".http" to
the filename so that people do not confuse the response with HTML
error pages, and to use absolute paths, since files are read
before any chroot is performed.
So, the file should contain a complete HTTP response but you're trying to serve JSON only.
The documentation further says that:
For better HTTP compliance, it is
recommended that all header lines end with CR-LF and not LF alone.
The example configuration, for example,
errorfile 503 /etc/haproxy/errorfiles/503sorry.http
shows the common practice of .http extension for the error file.
You can find samples of some default error files here.
Sample (504.http):
HTTP/1.0 504 Gateway Time-out
Cache-Control: no-cache
Connection: close
Content-Type: text/html
<html><body><h1>504 Gateway Time-out</h1>
The server didn't respond in time.
</body></html>
So, in your scenario, 504.http would be like this:
HTTP/1.0 504 Gateway Time-out
Cache-Control: no-cache
Connection: close
Content-Type: application/json
{
"message": "Gateway Timeout"
}
Also, you need to keep the file size under limit i.e. BUFSIZE (8 or 16 KB) as described in the documentation.
There might be some error logs for not serving your JSON file. You might want to look at HAProxy's logs again thoroughly. Just to be sure.
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).
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
I am told to upload an image to a server by sending a JSON as a request.
JSON is sth like below:
{"action":"setMap","data":{"mapName":"myMapName","mapURL":"http://tinypic.com/myimg"}}
I do not know how to use TELNET to POST a JSON.
i guess i should write something like below
terminal>telnet my.ip.num.ber port
POST /setMap HTTP/1.1
but dont know how to continue.
Should i write
DATA : {"action":"setMap","data":{"mapName":"myMapName","mapURL":"http://tinypic.com/myimg"}}
How can i get the JSON sent?
I can't understand why you want to use Telnet. Telnet can be useful to quickly test chatty protocols, and even if HTTP is chatty to some degree, it's very cumbersome to upload an image (plus, from the given service name, setMap, I guess the service doesn't really let you upload an image, but just insert a record in the database pointing to an image accessible on another service).
What you are asking is something like:
$ telnet example.com 80
> POST /setMap HTTP/1.1
> Host: www.example.com
> Content-Type: application/json; charset=utf-8
> Content-Length: 1234
>
> {"mapName":"myMapName","mapURL":"http://tinypic.com/myimg"}
>
Note that it's just an example. You have to replace connection parameters (host, port), content-type, content-length and the actual JSON data - and this we can't know because depends on the actual service implementation.