I have set up my EC2 load balancer health check to point to a url with a # in it like /#/applications
When I ssh into the box and curl the url I get a Response code of 200.
However the load balancer gives this error:
Health checks failed with these codes: [400]
If I change the health check URL to be / then the load balancer say it is fine.
I am suspecting it could be a url encoding issue. Are there any restrictions on what characters are allowed in the URL ?
# is not a valid character in the request URI. The # symbol marks the beginning of the URL fragment.
When you access a URL with #, the URI is truncated by the browser at the # before it is sent to the server. Servers never see this -- it's for client-side use only.
It is thus invalid in a health check and the server is correct to reject it as 400 Bad Request. Access a URL on your site with a fragment from a browser and you will notice that the # is not logged by the web server because the browser doesn't send it.
If for some reason you're actually needing a url-encoded #, that would be written as %23 but I would not expect this to be what you are looking for.
Related
In my GCP project am a doing a Host and path rules redirect on one of my load balancers. I am trying to get the redirect to pass the query parameters, but it is not.
Essentially trying to do:
subdomain.domain.com?foo=bar -> www.domain.com/path?foo=bar.
The redirect works to the path, but it does not keep the query params. From what I can see here, it should work.
https://cloud.google.com/load-balancing/docs/https/traffic-management#redirects
Redirect to a different URL formed by modifying the host, path, or both the host and path portion of the URL, and either stripping out or retaining any query parameters.
In Google Cloud, the stripQuery field can also be used with a Load Balancer, specifically the GCP HTTP(S) Load Balancer. This feature allows you to configure whether the query string present in the incoming request's URL will be included or removed when the request is forwarded to a backend service.
When stripQuery is set to false, the query string will be included in
the path when forwarding traffic to the backend service.
i.e: if a request is made to "example.com/path?key=value", and stripQuery is set to false, the request will be forwarded to the backend service as if it were made to "example.com/path?key=value".
By disabling the stripQuery feature in Google Cloud Load balancer we can forward the query params to the new host we have redirected to.
Here is a configuration YAML we can use to redirect the site to another site preserving the query parameters.
defaultService: projects/example/global/backendServices/example-test
name: example-matcher1
routeRules:
- urlRedirect:
stripQuery: false
hostRedirect: ie.example.com
redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
If you are using DefaultRedirect in Advanced host and path rule:
You should uncheck the Strip query in Google Cloud Load Balancer Edit Page for Advanced Route Rules Routing Rules .
Reference:
enter image description here
I am trying to switch our site from HTTP to HTTPS. In some scenarios, we need the site to use HTTP and at other times, HTTPS. I inted to use CGI to determine whether the request is HTTP or HTTPS.
As far as I can tell, the JSON requests must match the original protocol request. If you request, HTTP:// example.org you must call JSON with HTTP:// example.org /file.JSON. If you request, HTTPS:// example.org/ you must call JSON with HTTPS:// example.org/file.JSON.
Normally, I would use CGI variables to tell me whether the request is HTTP or HTTPS. I can test for CGI.HTTPS to see if it is on or off. I can check CGI.SERVER_PORT too see if it is 80 or 443. I can check CGI.SERVER_PORT_SECURE to see if it is 0 or 1.
When I view our web site in every browser, I can dump the CGI variables and get what I expect 100% of the time.
When a few other people in our office and outside our office make the same request, they get CGI variable values that suggest their request is NOT secure. CGI.HTTPS will show off. CGI.SERVER_PORT will show 40. CGI.SERVER_PORT_SECURE will show 0. Every other indicator will show that the site is secure in every browser, but the CGI variable values say it's not secure.
The site behaves flawlessly 100% for everyone for dev and stage. Only in live, which is behind a load balancer, does this issue exist (for some people).
Is this a load balancer issue? Is this certificate settings issue? Why are my CGI variables lying to me? How can I work around this issue?
Hi i created ALB listener 443 and target group instance on 7070 port (not-ssl)
I can access instanceip:7070 without problem , but with https://elb-dns-name not able to access.. instance health check also failed with 302 code
ALB listener port https and instance is http protocol ,
when i browse with https://dns-name it redirecting to http://elb-dns-name
you get 302 when performing URL redirection, any ELB Health check will look for success code 200 for the health check to pass. In ALB, this can be configured under health check in the ELB console.
To modify the health check settings of a target group using the console
Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
On the navigation pane, under LOAD BALANCING, choose Target Groups.
Select the target group.
On the Health checks tab, choose Edit.
On the Edit target group page, modify the setting Success Codes to 302 or as needed, and then choose Save.
I stuck with the same problem in AWS ALB (Health checks failed with these codes: [302])
Configuration:
Tomcat 9 servers that are listening on port 80 only
ALB health check path was set to "/my_app_name" expecting to serve health check from the application's root index page.
My configured health page is not expected to do any redirects, but to return HTTP/200 if server is healthy and HTTP/500 if unhealthy.
The proposed solution just to add HTTP/302 as a success code is absolutely WRONG and misleading.
It means that the page's internal health check logic isn't run, as HTTP/302 redirect code just shows common ability of the server to respond.
The problem was in Tomcat server itself that in the case of request to "/my_app_name" was redirecting with HTTP/302 to "/my_app_name/" (pay attention to the slash at the end).
So setting health check path to "/my_app_name/" fixed the problem, health check logic runs well and HTTP/200 is returned.
add this annotation in your ingress controller it will modify the success code and nodes will be in healthy state.
alb.ingress.kubernetes.io/success-codes: 200,404,301,302
I run into the same issue recently, and as suggested by #SudharsanSivasankaran we have edited the health check settings at the target level.
But we have kept the 200 only status code and instead updated the path to directly hit the page the redirection goes to.
For instance if a website hosted under instance:80 needs the user to be logged on and redirect it to the /login page, all we need to do is add the /login path in the health check.
I had a similar case where I'm offloading TLS on the ELB and then sending traffic to port 80 with plain HTTP. I'm always getting the 302 code from the ELB.
You can change the status code for the target group and specify the success code as 302, but I don't think that is a very good idea. Since you may encounter a different status code if you changed some configuration in your Apache or htaccess files which may cause your instance to put out of service. The goal of Health Check is identify faulty servers and remove them from the production environment.
This solution worked great for me: https://stackoverflow.com/a/48140513/14033386
Cited below with more explanation:
Enable the mod_rewrite module. In most Linux distros it's enabled by default when you install Apache. But check for it anyway. Check this: https://stackoverflow.com/a/5758551/14033386
LoadModule rewrite_module modules/mod_rewrite.so
and then add the following to your virtual host.
ErrorDocument 200 "ok"
RewriteEngine On
RewriteRule "/AWS-HEALTH-CHECK-URL" - [R=200]
AWS-HEALTH-CHECK-URL is the one you specify in the health check settings.
This solution will always return 200 code that specific URL as long as your server is active and serving requests.
In my case I had a domain www.domain.com
but by default when you accessing the domain and you are not logged in you are immediately redirected to www.domain.com/login
... and that is something that caused the problem
So you have 2 options:
Go to your aws target group -> health check and change your default path / to the new one which in my case was /login. I'm really sure if login endpoint works - website works too.
Go to your aws target group -> health check and change your default status code from 200 to 200,302. It is definitely less appropriate way but still acceptable, depends on the case
I have a system I want to test that first hits a Tomcat application which is essentially a load balancing redirect.
So the first url that is requested is
http://load.balance.server/redirector/
That URL redirects the browser to the next available server configured such as:
http://target.server.4/targetApp/
or
http://target.server.5/targetApp/
etc...
In my JMeter test case, after the http://load.balance.server/redirector/ request, I created a 'Regular Expression Extractor' to extract the IP address from the URL.
Then the next entry is going to be:
http://target.server.[4,5,6]/targetApp/
But when the RegEx extractor runs, it only returns load.balance.server from the initial request, not target.server.[4,5,6] from the redirected request like I want.
Thus, the subsequent ${HOST} entries for the http-requests are pointing to load.balance.server not to target.server.[4,5,6] so the test is failing.
Can someone help me capture the target redirected IP for testing such as testing a load-balanced cluster?
Put regexp extractor as child of http sampler that has a redirect response
uncheck follow redirect in sampler
Check headers in regexp extractir
Check your regexp , what is it ?
I deployed a war file into the elastic beanstalk but i keep getting this error:
health check URL misconfigured
and my environment is set to red.
I gave my applications first html page as the URL for health checkup.
Is there anything missing?
The health check url must reply with a http status code of 200 (ok), are you sure your root page that you pointe at does that?
Also keep in mind that the elb will load that page fully at every interval you have set, which counts as bandwidth and possibly db/disk IO if it is a really complex page.
If it is, you mght want to jist add a blank hc.html file to your webapp that the health check can load or something simple like that.
or also you can try this command to check url health
curl -i -X HEAD http://qwert.elasticbeanstalk.com