Auth 2.0.
"code" parameter is required to perform
POST /.../oauth2/v2.0/token
with code value.
In Fiddler code value could be found in Location header of response to /kmsi request:
However, here is no Location header in JMeter for the same request:
Why? Are there any tip to get Location header in JMeter too?
If you're seeing different response it means that
Either you're sending a different request. In this case inspect request details from JMeter and from the real browser using a 3rd-party sniffer tool like Fiddler or Burp, identify the inconsistencies and amend your JMeter configuration so it would send exactly the same request as the real browser does (apart from dynamic values which need to be correlated)
Or one of the previous requests fails somewhere somehow, JMeter automatically treats HTTP responses with status codes below 400 as successful, it might be the case they are not really successful, i.e. you're continuously hitting the login page (you can check it by inspecting response data tab of the View Results Tree listener). Try adding a Response Assertions to the HTTP Request samplers so there will be another layer of explicit checks of the response data, this way you will get confidence that JMeter is doing what it is supposed to be doing.
Related
I call a http request,The reponse is html,but gatling get the response is incomplete.What should I do
I think a part of I need that is gatling supported resources.It is under the tag 'table'.
The server may not be returning the complete response due to an error or a problem with the server-side code. In this case, you should check the server logs to see if there are any errors, and you should also check the HTTP response headers to see if there are any indications of what went wrong.
The HTTP request may be failing or being blocked by a firewall or other network security device. In this case, you should check the network logs to see if the request is being sent and received successfully, and you should also check any network security settings to ensure that the request is not being blocked.
The HTML response may not be well-formed or may be missing some elements, such as the 'table' element you mentioned. In this case, you should validate the HTML using a tool such as the W3C HTML Validator, and you should also check the HTML source to ensure that all required elements are present.
User issue, as concluded on the Gatling community forum.
We have an API published on WSO2. It works perfectly.
When I send my request like the picture below, it responses 200 as I wanted:
I just wanted to test my request by adding more deleted=false query. So, I can send request until the request's size is 5.75 KB. I see stil 200 OK nicely. You can see on picture below:
But, if I reach request size 5.76KB by adding 1 more deleted=false query, I see this error:
As I searched on internet, I see that the REST API supports Uniform Resource Locators (URLs) with a length of up to 6000 characters.
My question is, how can I extend this limit? Is there any way to do that ?
As per the shared screenshot, it seems the Backend itself is responding back with a 400 Bad Request status code. The API Manager doesn't have any restrictions on large query parameters in the URI. So, this error is coming up from your actual Backend service, which is not able to handle a large request.
To confirm this behavior, you can enable the WIRE logs in the API Manager server and troubleshoot the behavior. If the request is dispatched to the Backend and the Backend is responded with 400 Bad Request means, the Backend is only capable of handling requests up to 5.75 KB in your case.
Also, as an alternate check, you can also try invoking the actual Backend service URL from the Postman (direct invocation and not via WSO2) and verify the behavior with large requests.
Given below are few documentations related to enabling WIRE logs and understanding the WIRE logs
WSO2 API Manager v3.1.0: Enable WIRE Logs
WSO2 API Manager v2.6.0: Enable WIRE Logs
How to read and understand WIRE Logs
I have a Jmeter script where during replay, Post request is displaying as Get request and the parameters in the request are not sent to the server. Due to this, correlations are failing at this request.
One of the parameters in the request is ViewState with so many characters. Is this large parameter value causing the above issue? How to proceed now?
Most probably you're sending a malformed request therefore instead of properly responding to a POST request you're being redirected somewhere (most probably to Login page)
Use View Results Tree listener in HTML or Browser mode to see what page you're hitting in the reality
With regards to the ViewState, "so many characters" is not a problem, the problem is that these are not random characters. ViewState is being used for client-side state management and if you fail to provide the proper value you won't be able to move further so you need to design your test as follows:
Open first page
Extract ViewState using a suitable Post-Processor
Open second page
here you need to pass viewstate from the step 1 along with other parameters
More information: ASP.NET Login Testing with JMeter
Also don't forget to add HTTP Cookie Manager to your Test Plan
What I'm able to understand is the request may be getting redirected. This happens usually when the server expects a unique request. If you recorded the request, you may be possibly using older headers that carry old cookie information. Check your headers and then reconstruct the request.
Make sure you are not using old cookies anywhere. remove that cookie part from HTTP Header Manager everywhere.
I know it is a basic Question. Does a POST Json Request for update in User interface actually Post data in to database or just simulates the load for Post data without actually posting in database. But can someone please clarify
An HTTP Post request with the mandatory body (can be parameters, JSON, XML etc.), is intended to upload the data into server (upload images, Sign Up etc.), or to post data which server wants (to validate Sign in etc., not necessarily insert into the DB). So, it is basically how Server treats the data and the purpose.
If server puts the received data into the database, when performed the action using the browser, then the same operation expected when performed through JMeter also irrespective of the type of body data (JSON, XML etc). So, If you post the JSON data, it must be inserted into DB.
In DB, One thing to note is that server, either can directly dump the JSON data as JSON type itself or parse the JSON data and take the required values and store them in the Database. It depends on how the server is implemented.
So, how the server is implemented, it should behave the same way, whether you send the request from the browser or JMeter.
It depends on implementation. From JMeter's perspective API endpoint is yet another URL, JMeter sends a request to it, measures time between request and response and marks result as passed or failed depending whether HTTP Status Code is below 400 or not.
So it is up to you to check:
What does API endpoint actually do
What is correct request syntax (mandatory arguments, headers, cookies, URL parameters, whatever)
What is the expected result.
Optionally, what happens if "bad" request is being sent.
When designing a JMeter test always run it with 1-2 users and View Results Tree listener enabled to ensure that it does what it is supposed to be doing.
Coming back to your question: if HTTP response code is below 400, JMeter will mark sampler as successful, it won't check response body or database so I would recommend using the following test elements for confirmation:
JDBC PostProcessor - to check whether database was updated as a result of the request or not.
Response Assertion - to check that API response doesn't have errors, status code, variables, returned from the database, etc.
I got an eccentric problem. I am trying to automate visiting a web site by using WebRequest and WebClient. I have observed all the post request header key-value pairs and posted data string in Firebug(request Header and Post tab). Then I simulated such request with WebRequest and put all the header parameter and posted data there. However when I do GetResponse() from this request instance, I always got an error page back that says some sessionID is short of.
Actually I have taken care to put previously(first step to open the Logon page) responded session cookie in the Header's cookie field for the request. And I can get the correct response back by simulating requesting the logon page(the 1st page), but cannot get through this authentication page. My post data is like userid=John&password=123456789&domain=highmark.And the authentication page request that carried out by browser succeeds every time.
Am I missing something in the request that may not be shown by firebug.If yes, can you give me some recommendation for the tools that may examine the entire request sent by browser.
I have solved this issue. The problem is I set the httpWebRequest instance's AllowAutoRedirect=true. Thus the effect is when I got the first response from the server, the httpWebRequest would continually to make another request asking for a different url that is replied in the response header's Location field.
The defect of HttpWebRequest class is when it is getting redirected, it does not include the Set-Cookies(Response's Header Field)'s cookies in the next request header, thus the server would deny such page request and may redirect again to another different page.
And the httpWebRequest.GetResponse() method only return the last responsed page back under the setting AllowAutoRedirect=true. And I got the totally different response than I expected.
Also in this solving process, I need to thank to a distinguish Http Traffic examining tool:IEInspector Http Analyzer(http://www.ieinspector.com/httpanalyzer/). The great feature of this tool is it can examine not only the http traffic from browser but also what your process's httpWebRequest made. And also it can display in text format the raw stream of those request and response. Although it is a commercial software, you can try it for 15 days. I am quite happy with what it tells me(in well-formed details) and I like to buy it as well.