I am trying to send GET HTTP requests to a paginated endpoint. The challenge is I do not know the page size beforehand therefore I have to send a request to get page number and interate till the end. I have tried Camel HTTP but I was not able to make it send dynamic requests based on first (or previous) response. I am currently testing recipientList to generate HTTP URLs by sending the first request and use the simple method as processor. Since Camel is really new for me, I am not sure if this is the best way to do like this.
I would be really grateful if someone could show some direction on this. Thank you
When I understood your question correct, you have to make an initial request to get the first page.
In the response you probably get the number of pages and then you want to get all remaining pages.
You could give the Camel Loop EIP a try for the remaining pages.
Pseudo-Route:
.from("whatever triggers the page retrieval")
.setHeader("currentPage", constant(1))
.to("http:target/page/1")
// dont know what you want to do with the pages
... continue processing of the first page
.setHeader("numberOfPages", simple("extract the number of pages somehow"))
.loopDoWhile(simple("${header.currentPage} <= ${header.numberOfPages}"))
.toD("http:target/page/${header.currentPage}")
// dont know what you want to do with the pages
... continue processing of the current page
.end
It really depends on what you need to do with the pages you retrieve. For example if you have to aggregate them, I am not sure if you can access an aggregated result from inside the loop.
Is there a way for all Receive samplers to ignore specific responses in JMeter and wait for the one that we are interested?
To be more precise, we have created a jmx file that contains a large flow like a user would create on the browser. Each request sent is followed by a response, so we use a request handler followed by the corresponding receive handler for each call. And everything seems to work fine.
But there are cases that another kind of response may arrive, which is not the one we expect in our flow, but it is triggered by another independent mechanism. You can think of it like notifications sent to the user that is doing the flow and are independent of the flow itself, but theu are received in the channel (for us inside the websocket connection).
So we are trying to find a way to ignore a specific set of responses that may come while we are running the tests.
We firstly tried to add a While Controller in each receive sampler that checks if the content is of the desired type and if not loops again. But this solution has 3 disadvantages :
we have to add the sampler for the specific receive twice - one before the while element and one inside the element because we have to first extract the received data and while does not execute its contents before doing the while condition check
we have so many pairs of send-receive in our jmeter test script , that we have to add so many while controllers inside the script
since the received message may not be of the type we expect but another one that we want to ignore, then we cannot add a Response Assertion because it will fail if the notification arrives, so we have to verify the content indirect -> in the condition of the while loop
We use apache-jmeter-5.3.
So we are wondering if we could do another kind of configuration in order to avoid all these while loops.
It may be irrelevant to the solution, but we use websocket through "WebSocket Samplers by Peter Doornbosch".
Thanks
You don't have to, just amend your While Controller's condition to accept undefined variable as well
Sounds like a potential use case for using Module Controller to avoid code duplication
If you're getting the response you don't expect you can change the response body using JSR223 PostProcessor to the one you expect, example code
if (!prev.getResponseDataAsString().contains('foo')) {
prev.setResponseData('foo', 'UTF-8')
}
Sorry for my poor English, and thank you in advance.
I'm trying to make a thread group that makes jmeter logged in our system.
to accomplish this, I need to POST data which contains ID, password, and token.
The token generated every time when the page has opened and hold in hidden value.
So, the usual solution which is like GET response, do the regular expression extractor, and make the value variable and POST it later request doesn't work for me.
since the token become different from when jmeter GET token and POST it.
Then, I found a parallel controller and this might be a solution for me.
but I can't find a way to do it.
also, there are no references in my mother language(Japanese).
I want POST token to certain login action so I need to do regular expression extractor with parallel controller.
then POST the token with ID and password at same time.
I want to know the way of the above or if it's impossible, is there any alternative solution that might work for me.
Thank you a lot for your help.
Don't worry about language at all :)
I will add a solution according to how I understand your problem.
As I understood, your scenario is,
We Request a page
We will get a response with token
We fetch the token and send the next request with the token
We will get a response with a different token
Need to fetch the new token and send another request
In this case, I think you are trying to use the first token in all the requests. Without doing that what if you fetch the token per each request?
The problem with the parallel controller is if you want to fetch the token from a previous request. It might not work.
Please correct me if I haven't understood the question correctly
Parallel Controller is not something you should be using, it's for simulating AJAX requests as JMeter cannot execute JavaScript like browser does and hence cannot run multiple HTTP request samplers in parallel with one virtual user.
Your test plan structure should be much simpler, to wit:
HTTP Request sampler (to get login page)
a Post-Processor (most probably you're looking for CSS Selector Extractor) to get the values from hidden fields
HTTP Request sampler (to perform login)
See Variabilize and Correlate the script chapter for more details on the concept
I need to simulate a test scenario where my application sends a request with 100s of queries. On the back-end, this request is broken down into requests containing a single query each. So a request from Jmeter with 100 queries will become 100 requests on the back-end. Now - the response from the back-end could either contain the requested data for each of those queries OR contain a unique queryID. Sending back a queryID is server's way of telling that this query is still running. For example, if Jmeter sends a request with 100 queries, it might get back data for 80 and 20 unique queryIDs. So my application under test makes a callback request with those 20 queryIDs every 15 seconds until it gets back the requested data or timeout.
Here is what I have implemented so far.
-main_request_with_100_queries
--XPath_extractor_to_extract_any_queryIDs_found
-if_controller_to_check_if_queryID_MatchNr_is_greater_than_0
--15_second_pause
--beanshell_preprocessor_to_create_the_request_body_with_all_queryIDs
--callback_request_with_queryIDs
What I want to implement is to have another XPath extractor for my callback_request and if any queryIDs are found, then go back to the if_controller
I'm trying to make this work by using a module_controller but so far no luck. Has anyone ever implemented something like this? Can anyone suggest some ideas?
You can use While Controller to keep making the request until there is a queryID in the response.
While Controller [ "${querid.present}"=="true" ]
HTTP Request
Pre Processor [to_create_the_request_body_with_all_queryIDs]
Post Processor [to check for query ID. if no query id - change querid.present to false ]
If possible, try to use Regular Expression Extractor. xpath is very slow and might affect your performance of the script. Check here for more details.
Creating modular test script in JMeter.
Several of my ajax applications in the past have used GET request but now I'm starting to use POST request instead. POST requests seem to be slightly more secure and definitely more url friendly/pretty. Thus, i'm wondering if there is any reason why I should use GET request at all.
I generally set up the question as thus: Does anything important change after the request? (Logging and the like notwithstanding). If it does, it should be a POST request, if it doesn't, it should be a GET request.
I'm glad that you call POST requests "slightly" more secure, because that's pretty much what they are; it's trivial to fake a POST request by a user to a page. Making it a POST request, however, prevents web accelerators or reloads from re-triggering the action accidentally.
As AJAX, there is one more consideration: if you are returning JSON with callback support, be very careful not to put any sensitive data that you don't want other websites to be able to see in there. Wikipedia had a vulnerability along these lines where the user anti-CSRF token was revealed via their JSON API.
All good points, however, in answer to the question, GET requests are more useful in certain scenarios over POST requests:
They can be bookmarked
They can be cached
They're faster
They have known consequences (assuming they don't change data), so visiting them multiple
times is not a problem.
For the sake of posterity, updating this comment with the blog notes re: point #3 here, all credit to Omar AL Zabir (the author of the referenced blog post):
"Atlas by default makes HTTP POST for all AJAX calls. Http POST is
more expensive than Http GET. It transmits more bytes over the wire,
thus taking precious network time and it also makes ASP.NET do extra
processing on the server end. So, you should use Http Get as much as
possible. However, Http Get does not allow you to pass objects as
parameters. You can pass numeric, string and date only. When you make
a Http Get call, Atlas builds an encoded url and makes a hit to that
url. So, you must not pass too much content which makes the url become
larger than 2048 chars. As far as I know, that’s what is the max
length of any url.
Another evil thing about http post is, it’s actually 2 calls. First
browser sends the http post headers and server replies with “HTTP 100
Continue”. When browser receives this, it sends the actual body."
You should use GET where you're doing a request which has no side effects, e.g. just fetching some info. This request can:
Be repeated without any problem - if the browser detects an error it can silently retry
Have its result cached by the browser
Be cached by a proxy
These things are all good. Anything which is only retrieving data (particularly public data) should really be a GET. The server should send sensible Last-Modified: and Expires: headers to allow caching if required.
There is one other difference not mentioned by anyone.
GET requests are passed in the URL string and are therefore subject to a length limit usually dependent on the browser. It seems that most are around 2000 chars.
POST requests can be much much larger - in fact not limited really. So if you're needing to request data from a web server and you're passing in lots of parameter information then a POST request might be the only option.
So, as mentioned before really a GET request is for requesting data (no side effects) while a POST request is generally used for transmitting data back to the server to be stored (with side effects). e.g. Use POST to upload a file. GET to retrieve a file.
There was a time when IE I believe had a very short GET URL string. Some applications like Lotus notes use large numbers of random characters to represent document id's. I had the displeasure of using another product that generated random strings so the page URL was unique each time. The random string was HUGE... and it didn't always work with IE6 from memory.
This might help you to decide where to use GET and where to use POST:
URIs, Addressability, and the use of HTTP GET and POST.
POST requests are just as insecure as GETs. The main difference is that POST is used to modify the state of the server application, while GET only requests data from it.
The difference matters when you use clean, "restful" URLs, where the URL itself specifies the resource, and the different methods trigger different actions on the server side.
Perhaps most importantly, GET is book-markable / viewable in url history, and searchable with Google.
POST is important where you don't want the event to be bookmarkable or able to be typed in as a URL - otherwise you (or Google crawling your URLS) could end up accidentally doing things like deleting users from your system, for example.
GET
POST
In GET method, values are visible in the URL
In POST method, values are not visible in the URL.
GET has a limitation on the length of the values, generally 255 characters.
POST has no limitation on the length of the values since they are submitted via the body of HTTP.
GET performs are better compared to POST because of the simple nature of appending the values in the URL.
It has lower performance as compared to GET method because of time spent in including POST values in the HTTP body
This method supports only string data types.
This method supports different data types, such as string, numeric, binary, etc.
GET results can be bookmarked.
POST results cannot be bookmarked.
GET request is often cacheable.
The POST request is hardly cacheable.
GET Parameters remain in web browser history.
Parameters are not saved in web browser history.
Source and more in depth analysis: https://www.guru99.com/difference-get-post-http.html