Haproxy behind ELB - haproxy

I have HAproxy is behind an AWS ELB. As soon as i remove the ELB, i can get the custom error page. but, with ELB in the front of Haproxy, i get HTTP/1.1 504 GATEWAY_TIMEOUT Content-Length: 0 Connection: keep-alive.
Can anyone tell me what is going on please? Thanks
errorfile:
HTTP/1.0 403 Forbidden
Cache-Control: no-cache
Connection: close
Content-Type: text/html
<html><body><h1>403 Forbidden</h1>
Request forbidden by administrative rules.
</body></html>

Me and a coworker just had the same problem. After receiving the timeouts, and reading amazon definition for this type of http code, i got in my head my error file was "malformed". After a lot of trys, we managed to discover that there is something funny with the CL-RF (new lines) on the error file "header".
I downloaded HaProxy default file from their git (https://raw.githubusercontent.com/haproxy/haproxy/60220bbc4b6b3c4279d3c96232cf2c2461ecc55e/examples/errorfiles/503.http) and when you open it on vi(m) it has a ^M (CR) sign on the headers(everything before the body, including the empty line separating them). If you cant download it, you could just write it (just the top part) on wordpad or something like it (dos) and then send it to you unix machine.
So i wrote my on file using their header and now everything works fine.
Cheers.

Related

spring gateway always returns 301, how to continue processing

This is clarification of the OP
I have a spring gateway that uses eureka server to route requests to registered spring boot eureka clients.
What I am seeing is that every request results in a 301 redirect containing a Location header. It seems that because the request is received on https://my-api.io/payment/payment-intent spring-gateway looks it up based upon these rules:
server.forward-headers-strategy=framework
feign.hystrix.enabled=false
spring.cloud.config.discovery.enabled = true
....
spring.cloud.gateway.routes[11].id=orders-service
spring.cloud.gateway.routes[11].uri=lb://orders-service
spring.cloud.gateway.routes[11].predicates[0]=Path=/payment/**,/order/**
spring.cloud.gateway.routes[11].predicates[1]=Method=GET, POST
spring.cloud.gateway.routes[11].predicates[2]=Header=APIKEY, (.*)
spring.cloud.gateway.routes[11].filters[0]=AuthorizationHeaderFilter
## these next two apparently have no impact
spring.cloud.gateway.routes[11].filters[1]=RewritePath=/(?<segment>.*),/payment/$\{segment},/order/$\{segment}
spring.cloud.gateway.routes[11].filters[2]=RedirectTo=301, lb://orders-service
And then returns the Response Headers:
Server: awselb/2.0
Date: Tue, 24 Jan 2023 17:58:36 GMT
Content-Type: text/html
Content-Length: 134
Connection: keep-alive
Location: https://my-api.io:8081/payment/payment-intent
If I enable "follow redirects" in Postman or curl, then it works fine. But that won't work in a mobile app, so I really need to have spring-gateway just route the call on first pass. I don't know if this is because the routes.uri defines the as coming from the load-balancer (since ports are dynamic and there are likely multiple instances) url so it seems like a different url or what.
I am desperately trying to find a way so that the request is just processed and not bounced back with a 301.
Now that I have context around the issue it turns out the issue was not with Spring Gateway since its just a passthru (after some validation). Thanks to spencergibb I was able to rule out gateway and realize it was a forwarding issue in AWS.

REST client gives error, while HTTP looks fine

My interface (an MKR Wifi 1010 Arduino) runs a very simple REST API, but when testing it with Mulesoft's Advanced Rest Client, I get this error:
The requested URL can't be reached
The service might be temporarily down or it may have moved permanently to a new web address.
The response status "0" is not allowed. See HTTP spec for more details: https://tools.ietf.org/html/rfc2616#section-6.1.1
When I check it with telnet though, it looks fine:
[bf#localhost ~]$ telnet 192.168.178.185 80
Trying 192.168.178.185...
Connected to 192.168.178.185.
Escape character is '^]'.
GET /api/gps HTTP/1.1
Host: 192.168.178.185
HTTP/1.1 200 OK
Connection: close
Content-Length: 9
Content-Type: application/json
"Success"
Connection closed by foreign host.
My question now is, is the rest client broken, or am I missing something in my reply? Of course I want any REST client to be able to process my interface correctly.

Uber API issue with CORS

First time asking a question here. I'm a beginner at this, but i'm truly stumped at the problem i'm facing.
Browsers in use:
Safari and Firefox (both on Mac OS Sierra)
Firefox (Linux - Ubuntu 16.04.2)
I am registered as an Uber Developer and have registered an App in the Dashboard. I'm only using the Server Token for authentication at the moment. In the Dashboard, I have set the following entries in the "Authorizations" tab of the App for CORS (Optional URI for CORS Support):
http://localhost:8000 <-- web server in my PC
https://subdomain.mydomain.com <--- remote web server
A few months ago i created a web app using HTML, CSS and JS (with Jquery v2.2.4) to play around with the Ride Estimates API and was able to get it to report data for many locations in my area successfully. Somehow it no longer works. I'm trying to fix that and improve the functionality. However, i just can't get past the initial query to the API because of CORS issues that were not existent before.
My API URL is:
https://api.uber.com/v1/estimates/price?start_latitude=8.969145&start_longitude=-79.5177675&end_latitude=8.984104&end_longitude=-79.517467&server_token={*********SERVER*TOKEN**********}
When i paste that in the address bar of the browser i get valid JSON:
{"prices":[{"localized_display_name":"uberX","distance":1.58,"display_name":"uberX","product_id":"811c3224-5554-4d29-98ae-c4366882011f","high_estimate":3,"surge_multiplier":1.0,"minimum":2,"low_estimate":2,"duration":420,"estimate":"2-3\u00a0$","currency_code":"USD"},{"localized_display_name":"X English","distance":1.58,"display_name":"X English","product_id":"8fe2c122-a4f0-43cc-97e0-ca5ef8b57fbc","high_estimate":4,"surge_multiplier":1.0,"minimum":3,"low_estimate":3,"duration":420,"estimate":"3-4\u00a0$","currency_code":"USD"},{"localized_display_name":"uberXL","distance":1.58,"display_name":"uberXL","product_id":"eb454d82-dcef-4d56-97ca-04cb11844ff2","high_estimate":4,"surge_multiplier":1.0,"minimum":3,"low_estimate":3,"duration":420,"estimate":"3-4\u00a0$","currency_code":"USD"},{"localized_display_name":"Uber Black","distance":1.58,"display_name":"Uber Black","product_id":"ba49000c-3b04-4f54-8d50-f7ae0e20e867","high_estimate":6,"surge_multiplier":1.0,"minimum":4,"low_estimate":4,"duration":420,"estimate":"4-6\u00a0$","currency_code":"USD"},{"localized_display_name":"Uber SUV","distance":1.58,"display_name":"Uber SUV","product_id":"65aaf0c2-655a-437d-bf72-5d935cf95ec9","high_estimate":7,"surge_multiplier":1.0,"minimum":5,"low_estimate":5,"duration":420,"estimate":"5-7\u00a0$","currency_code":"USD"}]}
I then proceed to set up JS (w/ JQuery) code in webpage...
var url = "https://api.uber.com/v1/estimates/price?start_latitude=8.969145&start_longitude=-79.5177675&end_latitude=8.984104&end_longitude=-79.517467&server_token={*********SERVER*TOKEN**********}";
$.getJSON(url, function(result){
console.log(result);
});
Uploading the HTML and JS to my remote web server and then loading the webpage in any of my browsers yields a 200 status from Uber API. However, the console log shows CORS blocking my request (PROBLEM #1):
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api.uber.com/v1/estimates/price?start_latitude=8.969145&start_longitude=-79.5177675&end_latitude=8.984104&end_longitude=-79.517467&server_token={*********SERVER*TOKEN**********}. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
Then, in the Inspector view of both Mac Browsers, under the Network / Resources areas, i see the 200 Status message from the GET request. However, along with the Response message (PROBLEM #2):
SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data
The Request Headers are:
GET /v1/estimates/price?start_latitude=8.969145&start_longitude=-79.5177675&end_latitude=8.984104&end_longitude=-79.517467&server_token={*********SERVER*TOKEN**********} HTTP/1.1
Host: api.uber.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://subdomain.domain.com/Uber/index.html
Origin: https://subdomain.domain.com
Connection: keep-alive
The Response Headers are:
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 19 Mar 2017 22:26:31 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Content-Geo-System: wgs-84
Content-Language: en
X-Rate-Limit-Limit: 2000
X-Rate-Limit-Remaining: 1998
X-Rate-Limit-Reset: 1489964400
X-Uber-App: uberex-nonsandbox, optimus, migrator-uberex-optimus
Strict-Transport-Security: max-age=604800
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Encoding: gzip
In Firefox for Linux i sometimes don't get the Syntax Error; i always seem to get it on the Mac Browsers. In Linux, when i do get that error, then clicking on the "Edit and Resend" Headers button (resending the Headers but without really editing the Headers), the Syntax Error disappears and the Response text actually shows the Uber API Object that is supposed to be there... but i still get the CORS Blocked message on the Console Log. I really don't understand why this is, but it seems contradictory. In the end, i am unable to get to use the API data that, using the same method months ago, i could get for several dozens of locations.
I have looked for answers in similar questions but so far have found none that apply to my case. Any help will be greatly appreciated. Getting really frustrated... really stuck here.
This issue was caused by the API not including the header correctly. This issue is resolved and the api is now working as expected. Also, the allow origin header will only be returned in a response if an origin is specified in the request.

webHDFS API returns Exception on every query

I setuped single node Hadoop cluster to perform some experiments with HDFS. Via web access all looks good, I created a dedicated folder and copied file from local system to it using command line. It all appeared in web UI. After it I to get access to it via WebHDFS.
For example:
curl -i "http://127.0.0.1:50075/webhdfs/v1/?op=LISTSTATUS"
But after that I get:
HTTP/1.1 400 Bad Request
Content-Type: application/json; charset=utf-8
Content-Length: 154
Connection: close
{
"RemoteException":
{
"exception":"IllegalArgumentException",
"javaClassName":"java.lang.IllegalArgumentException",
"message":"Invalid operation LISTSTATUS"
}
}
The same error I receive on any another command.
I have no idea what went wrong here. Can it be caused for example by missing some components or anything else during setup?
For HDP you can use following URL (with default port):
http://x.x.x.x:50070/webhdfs/v1/?op=LISTSTATUS
For MapR cluster (with default port):
http://x.x.x.x:14000/webhdfs/v1/user?op=LISTSTATUS&user.name=YOUR_USER

Unable to get whole http message

I am using curl for sending a POST HTTP message to my server. At Server side I am opening a socket and reading the data by using following code
recv(socket_Fd, (void *)ucBuffer, (size_t)((sizeof(ucBuffer) - 1)), NULL);
I am able to get the header of the POST message but in message body I am getting only one line , rest are missing.
Data I am receiving at server end.
POST /info HTTP/1.1
User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Host: 192.168.0.57:10000
Accept: */*
Content-Length: 356
Content-Type: application/x-www-form-urlencoded
Bhupesh Bhargava
In message header it's showing right content length but message body is missing. Any idea where I am doing wrong.
curl command I am using
curl --data-binary #/home/bhupesh/data_save2 http://192.168.0.57:10000/info
The curl command seems to be OK and if we go by the documentation here, the following should be true.
Data is posted in a similar manner as --data-ascii does, except that
newlines are preserved and conversions are never done.
So, this leaves us with the fact that there should be a problem in your Server implementation. It is not quite sure how you are getting the received stuff at the server, but you should be careful about sequencing what you receive by yourself. Here is an example how you could do that.