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.
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.
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
Time ago we set up a PEP proxy to secure the API our widgets are using. All have being working correctly until today, that we are receiving a 502 Bad Gateway error code for every call going through the proxy.
We have checked the requests are reaching our server and it is responsing correctly to them. The parameters added by the proxy (x-nick-name, x-display-name...) are defined correctly too.
We have also checked the requests outside wirecloud and all go well: we get the token properly and use it in the subsequent calls without problem.
We do not know where this error comes from, any ideas?
EDIT 06/11/2015
After Alvaro's new setting we are receiving the following error in the response body:
{
"description": "Connection Error",
"details": "('Connection aborted.', error(104, 'Connection reset by peer'))"
}
EDIT 09/11/15
Today, the code received in the request's response is different: 504 GATEWAY TIMEOUT
{
"description": "Connection Error",
"details": "('Connection aborted.', error(104, 'Connection reset by peer'))"
}
EDIT 16/11/15
Answering to Mr. Alonso's question:
1.- If we request directly to the server, the response is correctly displayed in the application.
2.- Here you can see the logs from the PEP Proxy with the new line added. As you can see the request is redirected correctly but the info is not displayed in the app.
Seems that the problem is in the PEP proxy side.
I've checked using other tools like curl (I obtained the connection details from the server log). Making the same request using curl gives the same result than using WireCloud: connection reset by peer. Also, if I make the request without the X-Auth-Token header, your service responds with an 401 error code. This is important, because it means that there is not a communication problem between the Mashup portal and your server. I don't know why, but the PEP proxy seems to be crashing when making the authenticated request from the Mashup portal (the same command works executing it from my machine).
I suggest you to restart the PEP proxy. If the problem persist, please attach any available info about the crash from the PEP proxy logs.
You can check three things to give us more information:
Try to remove the PEP and send the request directly to your service.
Introduce a new log in PEP to print the headers of the response: line 41 of lib/HTTPClient.js, log.debug("Headers: ", headers);
Try to send a request to the root path (directly to the tomacat or apache)
If not perhaps we can talk in private to check more information
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
My flash game needs to connect to my PHP Socket Server. Because of security things, a policy file has to be send to the flash client when it tries to connect.
The following is what I've done.
In Actionscript / Flex 3 / Flash:
Security.loadPolicyFile("http://[SERVER.IP]:9000/crossdomain.xml");
socket.connect(hostName, port); //connect to the socket
[rest of original code]
To make the socket server respond on the request, I added the following to the server:
elseif (preg_match("/policy-file-request/i", $buffer) or preg_match("/crossdomain/i", $buffer)) {
socket_write($socket, '<?xml version="1.0"?><cross-domain-policy><site-control permitted-cross-domain-policies="all"/><allow-access-from domain="*" to-ports="9000" /></cross-domain-policy>');
unset($read_sockets[array_search($socket, $read_sockets)]);
socket_shutdown($socket, 2);
socket_close($socket);
I however get the following error: "Ignoring policy file at (URL) due to missing Content-Type." So, I tried to fix this by adding a header right above my xml code:
socket_write($socket, "Content-Type: text/xml\n");
Unfortunately, I still get the same error. Am I giving the content type in a wrong way?
You need to return a valid HTTP response if you are going to use:
Security.loadPolicyFile("http://[SERVER.IP]:9000/crossdomain.xml");
If the flash is going to connect to your PHP socket server, just skip the above line and it will try the port itself and expect raw data instead of a HTTP response.
Try sending this:
HTTP/1.1 200 OK\r\nContent-Type: text/xml\r\n\r\n
Make sure nothing is sent before this.
Also, send a \r\n before the socket is closed.
you can load the policyfile from any port of the server using Security.loadPolicyFile() ... maybe you should simply serve it per http on port 80, load it from there and then connect to the server ...
also, by default, i think flashplayer 9 (upwards from some minor version) sends a policyfile request to port 943 by default ... so you might put a server there, to do that ...
a little side note: PHP was never designed for socket servers and is not very good at that ... if you can, try using Java, or NekoVM, that you can use with Haxe ... also Haxe remoting, as well as ThreadedRemotingServer might be of interest to you ... there's some good and clear tutorials on the Haxe site ...
Try it with \r\n after the Content-Type.
socket_write($socket, "Content-Type: text/xml\r\n");
Shouldn't you be using a xmlsocket on port 843?
if(trim($buffer) == '<policy-file-request/>') {
$policy_file =
'<'.'?xml version="1.0" encoding="UTF-8"?'.'>'.
'<cross-domain-policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.adobe.com/xml/schemas/PolicyFileSocket.xsd">'.
'<allow-access-from domain="*" to-ports="*" secure="false" />'.
'<site-control permitted-cross-domain-policies="master-only" />'.
'</cross-domain-policy>';
socket_write($socket, $policy_file.chr(0));
}
works fine for me, the client will request a policy file, disconnect, then reconnect after receiving the policy file