While validating my script, one of the request fails with assertion fail and response of that request is returning generic error. While observing the request and response of the request during validation with recorded one, found out that "X-Frame-Options: SAMEORIGIN" field is passed in the header of the response during validation.But the same fiekd is not there in the recorded response. Also Few discrepencies are there in cookies in the request.
I would suggest you to look at the previous requests/responses to make sure that everything went well before the request that got the error.
Sometimes the application does not send error but it does not mean that it works.
I do not think that this "X-Frame-Options: SAMEORIGIN" could have any impact on a replaying of a request. But maybe it's there because the request is not sending the right data. So it might just be a consequence and i guess it's the same thing for the cookie values especially on that server response if request sent did not contain the right data.
Hi Nouredine,
I have validated the requests and responses of the previous hits. Everything is working as expected till the request where the error is occuring. And the very preceeding request has 302 as response.I have attached the compared recorded and validation response of the same request. Please look into that.
Since everything is working as expected, I had to look into the request and response of the hit where the error occurred. And found some discrepencies.in the request and response headers
If i understand properly and looking at your screen shot you have differences on the response where you have a 302. So i would suggest you to now compare the request sent during validation since this 302 response is a little bit different.
One more thing. I saw in your screens shots that your application uses expiration date of cookies values with two digits like for example: Thu, 01-Dec-94 16:00:00 GMT
I don't know if it is the root cause of your issue but for sure it may be an issue when replaying with NeoLoad since that year using 2 digits "94" will be interpreted by NeoLoad as 2094 and not 1994. And it seems that the developers of the applications meant 1994 instead.
If you can contact the developers of your application you should ask them to use 4 digits instead.
I have already seen such issue with a WebSphere application server and a patch is needed. Please check that link
Thanks for the solution Nouredine. Regarding this I will connect with my Dev team. Meanwhile I need solution for the following question.
Since this is the client side cookies, Can't we manipulate these cookies with some reference? Because when I validated the script by unchecking the cookies options, script is passing and all the dynamic values are captured. But only the mentioned request which returns 302 response is returning generic error with http 200.And no cookies are passed in the header of the requests. So believing if I could do any cookie manipulation, then it will give some lead
You can manually handle the client cookie using a NeoLoad variable or a Javascript but in your case it's server cookies so you will not be able to overwrite them if NeoLoad handles them.
Something that you did not share is a request comparaison of the request that is failing when NeoLoad handles the cookies. The expiration date that i already mentioned could be an issue but i'm wondering if it's the only issue.
I compared the request sent during the user validation and the recorded one and there are too many differences. For example, in the user validation there's a list of cookies with empty values like this: JSESSIONID=""; ADRUM_BTa=""; ADRUM_BT1=""; etc....
So i'm not surprised that the response of that request during validation is different with the recorded one.
I think that the script is not working before that request. I would suggest you to check at the beginning of your recorded script where and when that JSESSIONID is sent by the server.
Then check the same response on the user validation panel to check if the server did send a JSESSIONID cookie value. If not then that means that the request sent is not correct. You may have to handle some dynamic parameters.
I would suggest you to reduce as much as possible the number of transactions of your script for debugging purpose. Only when it works fine add more transactions and make baby step like this till you can identify all the dynamic parameters.
