I have enabled the Health Checks under Traffic in the CloudFlare and it keep on shows the health check analytics as 403 response code mismatch error. cloudflare healthchecks error
But if i check my site from chrome browser network tab i get only 200 and not getting 403 status code as cloudflare health checks analytics mentions?
my domain name : https://dealsfinders.blog
How do i understand this discrepancy on status codes? I assume something wrong going with my origin server which is not caught when I test my site from a browser client? Why i can't replicate the 403 error on my browser client and caught by Cloudflare?
Related
I deployed an Odoo instance on ECS + FARGATE as a service, which is assigned to a target group.
On ALB I have a listener on port 443 with ACM that redirects the traffic on that target group.
The connection is working, I can reach the Odoo service from the ALB.
The problem is, Odoo can respond with 3xx codes, and I can see the url changing on the browser address bar. But instead of loading the new page, I get an error.
If resend the request directly with this same url, the one resulting from the redirect, the page loads as expected.
If I connect to the service directly, without ALB, it works fine.
From what I could understand, the ALB doesn't manage the 3xx response codes from the target group, so it gives an error.
What can i do to resolve this redirect problem?
EDIT:
Problem solved, here is what i tried:
I tried setting the listener on HTTP instead of HTTPS, and it worked fine.
After that, i reconfigured the listener on HTTPS, and added an HTTP listener which returned a fixed response. Tried to click an url of the server which returns a 3xx code, and instead of an error i got the fixed response.
In practice, the server behind the ALB listens on port 80, so when it issues a redirect, it does so on HTTP. The ALB receives in as HTTP, but wasn't listening. It was configured only on HTTPS. Hence the error.
I resolved configuring two listeners:
an HTTPS listener which forwards traffic towards the target group
an HTTP listener which redirects to HTTPS
On ALB I have a listener on port 443 with ACM that redirects the traffic on that target group.
It forwards traffic to the target group. It does not redirect the traffic.
The problem is, Odoo can respond with 3xx codes, and I can see the url changing on the browser address bar. But instead of loading the new page, I get an error.
Including the details of that error in your question would be a key detail that needs to be included in your question. You need to edit your question to include the details of that error in order to get more detailed help.
If resend the request directly with this same url, the one resulting from the redirect, the page loads as expected.
If resending the exact request with no changes works, then there is some issue in your server software or something. There is nothing about using an ALB that would make sending the request a second time suddenly work.
From what I could understand, the ALB doesn't manage the 3xx response codes from the target group, so it gives an error.
That isn't correct. The ALB will happily send any response, with any HTTP response code, from the server back to the client. The only issue you may run into is if the health-check URL configured on the target group is sending something other than a 200 HTTP response. The health check requests are the only requests that the ALB/Target Group examine the response code on.
JMeter URL redirection challenges from 302 to 200 status code
I'm trying to perform URL HTTP connection authentication with JMETER and facing challenges on redirection URL with JMeter from 302 to 200 status code within the organization environment. The office environment using windows authentication NTLM2 methods.
However I’m facing URL redirection blockage when I tried to navigate through an internal website as it stops when it reaches 302 status code and failed to navigate further to status code 200 through JMeter but when I display the same URL with chrome browser, it able to successfully display the web with status code 200 using chrome browser.
How does the URL Authentication work?
at 1st the given URL which includes end-user parameters were entered to display the web messages.[shows HTTP status code 302]
The URL then redirects to another portal login URL to acknowledge the authentication.[shows HTTP status code 302]
Problem/Issue:-
The URL only successfully performing the 1st 2 options but it failed to perform the final redirection to have status code 200
At the moment the HTTP result in Jmeter through "View Result Tree" and "View Result Table" is both showing status code 302
Limitation
I couldnt install any external chrome pluggin due to the security restriction within the given operating system environment
proxy has been included. in both "HTTP default Advance" option and "HTTP Advance" option with the relavent user proxy details, id and password
Additional Details
The website were build part of the liferay framework using java spring.
We notice through jmeter logs viewer that the "Pooling HTTP Connection Manager" being shut down as well.
I've included the log viewer from the JMETER in here
Challenges
I'm not sure what further configuration i should do to allow the 3rd redirection to be happened.
You need to add HTTP Authorization Manager, change "Mechanism" to BASIC_DIGEST and provide your domain and Windows credentials there
This way JMeter will be able to build a proper Authorization header and you will be able to proceed to your application
More information: Windows Authentication with Apache JMeter
My server side setup is like this : I have a google compute engine instance running nodejs server. It sits behind https load balancer.
So the issue is that if OPTIONS type request is sent with body(payload) to load balancer ip, it sometimes fail with 502. I have checked that in all these requests, node server is returning and logging correct responses. It works perfect if the request body is left empty.
However, when I directly hit GCE's ip, it works fine whether or not request body is there or not.
For e.g
this is the load balancer ip (with ssl enabled)
OPTIONS https://130.211.14.60/health
this is the direct GCE machine ip (without ssl)
OPTIONS http://104.199.159.212:8002/health
I have checked by sending requests multiple times(literally hundreds of times) using Postman app.
And this issue is only with DELETE and OPTIONS type requests. GET/POST/PUT works perfectly fine.
Is there anyone who can point me what the issue could be and how to solve it.
From Google's docs -
The HTTP(S) load balancer does not support sending an HTTP DELETE with a body to the load balancer. Such requests will receive an error message: Error 400 (Bad Request)!! Your client has issued a malformed or illegal request. Only DELETE requests without bodies are supported.
More info here.
This feature is now supported by Google Load Balancer, released in Dec '18.
More info here.
I've set up an SSL site on server 2012 using CCS and SNI. When attempting to navigate to it over a non-SSL link (http), the site throws a 404 error.
How can I get it to show the "This site requires SSL" message?
You need to add HTTP to your bindings in IIS.
Instead of showing "This site requires SSL" you should redirect your user to the equivalent SSL page (e.g. http://twitter.com/about would redirect to https://twitter.com/about).
It is bad for both end-users and SEO to display a message with a message asking the user to change the URL. If you look at different websites on the Web you can notice that this is automatic and doesn't require any action from the user.
I'm getting the http error 403.4 - Forbidden: SSL is required to view the resource error using IIS6, even though the url starts with https.
It's a classic asp site, that used to work until the path to the files was changed. The path had to be changed because the site had to be upgraded. After getting the error; putting back the original path doesn't either.
Does anyone have any idea what I should check to resolve the above mentioned error?
Try following Configuring SSL on a Web Server or Web Site (IIS 6.0) from Microsoft. It specifically mentions the error you get:
If you set your Web site to require
SSL, as in step 6 above, and you have
not completed setting up SSL for the
site, then users browsing your site
will receive this error: "HTTP Error
403.4 - Forbidden: SSL is required to view this resource." To avoid this
condition, either complete all the
steps in the list above, or go back
and clear the Require Secure Channel
(SSL) check box (see step 6).