I tried to change the uri of an incoming GET request to redirect it to a different URL.
What I did:
backend
httprequest set-uri https://www.example.com/ping
The example url works directly, but I receive 503 for requests that are directed there from haproxy.
What seems to be wrong?
You need to put 'server' directive after 'http-request' event if you rewrite the whole URL
Related
I am doing load testing for one website. Website actual address is configured with SSL so it is something like https://www.example.com
When I start load testing for pages with GET requests , Jmeter is sending 2 requests for each page, one with Http & second is Https. So I get in listener like this :
http://www.example.com
https://www.example.com
How can I tell to jmeter that site has only version with https so do not send request with http.
You need to add 'https' in the protocol section.
Its like if you hit your URL i.e. "https://www.example.com" by replacing "https" with "http" it will redirect to you "https" by default
Similar way if you not mentioned any protocol in your "HTTP REQUEST" it will take default value i.e. "http", and in listener you see both URL.
For making that it will hit only the "https" URL you need to put "https" in Protocol text box.
Refer the below snapshot:-
I have configured Jersey client to automatically follow HTTP 302 redirects:
DefaultApacheHttpClientConfig config = new DefaultApacheHttpClientConfig();
config.getProperties().put(ClientConfig.PROPERTY_FOLLOW_REDIRECTS, true);
Client client = ApacheHttpClient.create(config);
This works perfectly fine when I receive HTTP 302 for HTTP GET request: the client redirects me automatically and the last response I got from client is HTTP 202.
However, when submitting HTTP POST request that results in HTTP 302, the client does not redirects me automatically. I.e., the last response from the client is HTTP 302 and I need to follow redirects manually. This behavior seems counter-intuitive for me, as Web browsers are handling such redirects automatically. The use case also seems quite common, for instance, when trying to login with HTTP POST, you often get redirected to a new page.
Why is it so? And is there a way to handle it automatically, in a same way Web browser does it?
I'm getting this error when trying to make an ajax request in a custom module:
XMLHttpRequest cannot load https://www.vossmarket.com/index.php/shoppinglist/index/showLists/product/4294/form_key/6erZKqom1ynOWDKI/qty/1/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.vossmarket.com' is therefore not allowed access.
I'm assuming the problem is that I am calling https from the http, but I'm not able to figure out why it is calling the https. I've turned off https in the magento config (I changed secure_base_url to http://vossmarket.com and I turned Use Secure URLs in Frontend to "no"). Now all links stay http, but when I visit my custom module, it is still redirecting (302) to https. This happens to every link http://vossmarket.com/shoppinglist (my custom module), any other route stays http, but any route that hits my module in any ways 302s to https
Any ideas what might be happening or the best way to fix it?
Have you tried putting a file called crossdomain.xml in your web root (accessible by both http and https), ie at http(s)://vossmarket.com/crossdomain.xml
This should help define that cross site origin is allowed between http and https.
In your case, I think the custom module is upset about being accessed over http and is sending the 302 to your browser, so it would be a case of studying the controller action of the custom module to figure out why it is forcing https (instead of asking Magento what the secure URL is).
Actually, if you try this crossdomain.xml you will need the browser to request https out of the http loaded page otherwise I think you will still get the 302 redirect - but with crossdomain.xml in place you should be able to XMLHttpRequest from http://vossmarket.com to https://vossmarket.com
But, you know, often there is good reason for https so I think you should understand why https is being forced and also I don't know about that XML secure="false" - does it really mean an https request is returned over http? I hope not but I don't know.
For more information read up on CORS although your 'cross domain' is http crossing to https.
A CORS POST request (AJAX) made by my client server (running on Apache # port 443) to my REST server (running on Tomcat # port 8443), fails to trigger when tried over HTTPS.
Please note that all the requests function properly without SSL.
I have already set the withCredentials: true options in the request fields. And my Tomcat server also takes care of the appropriate headers :
response.addHeader("Access-Control-Allow-Origin", "https://localhost");
response.addHeader("Access-Control-Allow-Credentials", "true");
response.addHeader("Access-Control-Allow-Headers", "Content-Type");
response.addHeader("Access-Control-Allow-Methods", "OPTIONS, POST");
I also tried using Curl, but the issue persisted over SSL. However, the Tomcat server responds to all my requests when tried directly over Postman/through the browser.
Could someone tell me what I'm missing out here?
I'm assuming this is an issue with the preflight request. There are two types of CORS requests: simple, and not-so-simple.
The simple kind is either a GET or POST with no custom headers whose content type is "text/plain".
The not-so-simple kind is any request using custom headers, utilising request methods other than POST or GET, and using different content body types. These requests will be "preflighted"; that is the browser will make a preflight request on the clients behalf in order to determine whether or not the server will allow this request. The preflight request uses the OPTIONS method. I'm willing to bet if you use something like Firebug to have a look what's going on you'll see something like this in the Net tab: "OPTIONS activity" with a status of "Aborted".
Unfortunately the preflight request doesn't pass the client certificate to the server which is why your request is failing to trigger. You need to disable two way SSL in order to get it working. In Apache you can try changing the SSLVerifyClient to:
SSLVerifyClient optional
I've used this before in order to get my cross domain AJAX calls working over HTTPS.
Good luck.
In my application there is a client and a WCf REST service. For invoking some wcf service the client is doing an http POST even though the service is a GET.
i do not want to do any changes in the client or the service.
So is there a way where i can convert this POST request to GET and add the data coming in as the POST to the URL and invoke the REST service.
Thanks in advance.
You can use URL Rewrite to issue 3xx Redirect which will use GET method, but you will loose all POST data.
The only safe way known to me is to rewrite POST request to some another custom page, where you:
collect all POST data/variables;
convert them into GET variables (assemble proper GET request);
issue 301 (or 302) Redirect to the proper URL (it will have all POST data sent as GET variables).
Such rewrite to custom page should be easy -- you need to check what method is used (POST or GET) and only invoke it on POST. The rest will be handled in that post-to-get script.
The reason for all of this complexity is the difference in how POST and GET requests work: with GET all data is sent as part of URL while POST uses request body to transfer variable's data.