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 ?
Related
I have a website and I'd like to redirect traffic based on a dynamic product ID in the url.
This I'm doing with help of Google Optimize Redirect Test. Setup is based on a Regex to actually fetch the Original page which I want to redirect to an other page.
https://domain.de/en/products/brand/product/a002p00001EuNgzAAF should redirect to https://domain.de/en/our-products/brand/product/a002p00001EuNgzAAF
How can i setup the regex so that I can use the 18 digit product ID as an identifier?
I alread tried to setup a regex like
https:\/\/domain\.de\/en\/products($|\?.*) plus trying to add the expression (\d{18}) but failed in putting it in the right position.
I want to do something similar to this: Create AWS Application Load Balancer Rule which trim off request's prefix without using additional reverse proxy like nginx, httpd
Using AWS Load balancer, to redirect traffic from URL say /foo to /bar like this:
But only GET requests are routed correctly and POST,PUT,etc get routed as GET so I'm getting an error because my controller doesn't have those GET methods.
Is there a way to do this with AWS load balancer?
The question I linked is from 2016 so I was hoping something has changed in 5 years.
In case someone is using a client written in Golang, this is why redirected POST requests end up as GET on the server side:
https://github.com/golang/go/issues/18570
https://cs.opensource.google/go/go/+/master:src/net/http/client.go;l=514
In the section in which you define the condition you have to specify the http method, otherwise it will consider GET as default.
Example for the OPTIONS HTTP calls
You can use /* in the IF section with a path as a condition.
For example, IF /* THEN Redirect to.
Additionally, you can use one of more condition in the IF section such as host-header, http-request-method, query-string, source-ip
there's http request methode option
check this screenshot
you can put there PUT or POST or GET like:
this
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.
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?
I jmeter.properties I set "CookieManager.check.cookies=false" but cross domain cookies still aren't working.
For example going this guide and using their demo site setting a cookie with a domain of "blazedemo.com" works, but if I change the domain to anything else it fails.
JMeter sends only cookies that match the domain of server in the request.
The property you've set impact the way JMeter read cookies not the way it writes them.
To check, emit a http request towards one host for which you created the cookie, you'll see it works.