I have proprietary http based API to test from JMeter. Unfortunately some of the endpoints of the API are expecting http DELETE method with a request body (I know its questionable API design to use DELETE with request body, but I have no ability to change that API and need to test it).
How can I test it from JMeter? It seems that standard HttpRequest sampler silently ignores my body payload without any warnings. (When I try it in POSTMAN its sending a request body for DELETE method)
I did find an old JMeter plugin called HTTP Raw Request that somewhat helps but still doesn't auto-calculate "Content-Length:" http header for my body payload...so I have to do it manually for every test case - which is a pain for dynamically generated data payloads.
So my question still remains: How can I test HTTP DELETE with request body from JMeter?
Here is the screenshot:
NOTE1: Starting from jMeter ver. 3.1 (see bugzilla #60358) it was fixed for Http GET request to be able to send body in the request...but DELETE was not added.
NOTE2: See bugzilla #61443 for the DELETE request with body.
NOTE3: I'm using client implementation called "Java".
As per reference docs:
http://jmeter.apache.org/usermanual/component_reference.html#HTTP_Request
There are 2 implementations for http request sampler. The non default one called "Java" has this issue with not passing DELETE request body.
Luckily the default implementation called "HttpClient4" that correctly passes request payload for DELETE operation as per JMeter data entry screen.
To change implementations for http request sampler you have to go to "advanced" tab of the HTTP Request Sampler and select client implementation "HttpClient4" instead of "Java". Here is the screenshot:
After that when executed it correctly sends request payload for DELETE operation. Here is the screenshot:
Related
I am attempting to use the endpoint https://firestore.googleapis.com/v1/{parent=projects/*}/databases with more data needed per the documentation on Google's docs.
The goal is to be able to make this request with a standard http utility such as cURL.
I have attempted performing the request manually through the GUI with the Chrome network tab open, and I saw a request being made: https://firebasedatabase.clients6.google.com/v1beta/projects/XXXXXXXXXX/locations/us-central1/instances?databaseId=my-database&validateOnly=true&alt=json&key=secretkey
Per trial and error on another endpoint, I have found that the key parameter can be replaced with a Bearer Auth token in the header. Other than that I am at a dead end.
i have a fairly simple testplan with following steps recorded
Thread Group
Recording Controller
HTTP Authorization manager
GET https://xxxx/user/login
GET https://xxxx/accounts/list
GET https://xxxx/user/settings
GET https://xxxx/partners/list
GET https://xxxx/user/logout
When i run this, i see jmeter adding the authorization header in the first user/login request and server responds with 200 OK. This is OK
i extract the session token from the login response and put it as a variable into the subsequent http requests.
jmeter is not adding the authorization header in the subsequent accounts/list request - this is OK
but then jmeter is adding the authorization header into the subsequent user/settings request - this is not needed as it defeats the purpose of sending the session token.
Again jmeter is not sending the auth token in partners/list but is sending it again in user/logout request.
So question is how jmeter determines when to add the auth header and when not?
The desired behaviour i want is for jmeter to send the auth header in the first user/login request but not in any of the subsequent http requests.
Any pointers appreciated.
thanks
HTTP Authorization Manager will add Authorization header to all the HTTP Request samplers it its scope, if you place it at the same level with the HTTP Request samplers - it will add the header to all of them.
If you need to apply the HTTP Authorization Manager to 1st sampler only - move it to be the child of the first sampler.
More information: JMeter Scoping Rules - The Ultimate Guide
Recording any scenario adds up the Header Manager in all the Http requests.
You are doing it in correct way, however still you have to make few changes in your scripts to run seamlessly.
Delete all the subsequent Header Manager under the accounts/list,user/settings,partners/list & logout.
Post the Login Request > extract the session > Add a Header Manager after Login request and pass the session there.
All the further request should be in the same thread so that the session get passed to each request.
Also while recording there are multiple requests that gets captured and for each scenario Jmeter maintains the session under Header Manager, hence this should never be the case that one request is getting the session while others not.
Thanks for the answer that helps.
What i did and worked well in the mean time is add an explicit authorization header to the user/login request with a beanshell preprocessor to base64 encode the username / password.
thanks anyways
I have read many discussions on this, such as the fact the PUT is idempotent and POST is not, etc. However, doesn't this ultimately depend on how the server is implemented? A developer can always build the backend server such that the PUT request is not idempotent and creates multiple records for multiple requests. A developer can also build an endpoint for a PUT request such that it acts like a DELETE request and deletes a record in the database.
So my question is, considering that we don't take into account any server side code, is there any real difference between the HTTP methods? For example, GET and POST have real differences in that you can't send a body using a GET request, but you can send a body using a POST request. Also, from my understanding, GET requests are usually cached by default in most browsers.
Are HTTP request methods anything more than just a logical structure (semantics) so that as developers we can "expect" a certain behavior based on the type of HTTP request we send?
You are right that most of the differences are on the semantic level, and if your components decide to assign other semantics, this will work as well. Unless there are components involved that you do not control (libraries, proxies, load balancers, etc).
For instance, some component might take advantage of the fact that PUT it idempotent and thus can re retried, while POST is not.
The Hypertext Transfer Protocol (HTTP) is designed to enable communications between clients and servers.
HTTP works as a request-response protocol between a client and server.
A web browser may be the client, and an application on a computer that hosts a web site may be the server.
Example: A client (browser) submits an HTTP request to the server; then the server returns a response to the client. The response contains status information about the request and may also contain the requested content.
HTTP Methods
GET
POST
PUT
HEAD
DELETE
PATCH
OPTIONS
The GET Method
GET is used to request data from a specified resource.
GET is one of the most common HTTP methods.
Note that the query string (name/value pairs) is sent in the URL of a GET request.
The POST Method
POST is used to send data to a server to create/update a resource.
The data sent to the server with POST is stored in the request body of the HTTP request.
POST is one of the most common HTTP methods.
The PUT Method
PUT is used to send data to a server to create/update a resource.
The difference between POST and PUT is that PUT requests are idempotent. That is, calling the same PUT request multiple times will always produce the same result. In contrast, calling a POST request repeatedly have side effects of creating the same resource multiple times.
The HEAD Method
HEAD is almost identical to GET, but without the response body.
In other words, if GET /users returns a list of users, then HEAD /users will make the same request but will not return the list of users.
HEAD requests are useful for checking what a GET request will return before actually making a GET request - like before downloading a large file or response body.
The DELETE Method
The DELETE method deletes the specified resource.
The OPTIONS Method
The OPTIONS method describes the communication options for the target resource.
src. w3schools
When I make a multipart request using the POST method to my server, the request works fine.
Below is how I've set up my JMeter:
POST REQUEST
However, when I try to make a PUT request to the same URL, the request does not work.
PUT REQUEST
And the error on the server is
org.springframework.web.multipart.MultipartException: Current request is not a multipart request
This seems to be an issue on the JMeter, since that when I try to do the same request using Postman, the request using POST or PUT works correctly.
However, I want to use JMeter to test my application performance.
The question is: How to make PUT multipart request using JMeter?
As of JMeter 3.0 multipart/form is only available for POST method, while it appears to be possible for other http methods.
So it's a bug:
https://bz.apache.org/bugzilla/show_bug.cgi?id=60015
See also:
http://mail-archives.apache.org/mod_mbox/jmeter-dev/201609.mbox/%3cCAH9fUpbN5jVSNmJUWTFOQUoRM64LNdKY=j8ZjGWzRt6gDuNzdg#mail.gmail.com%3e
It should be fixed in next releases.
I'm trying to retrieve 3 response headers (Rails Devise Auth Headers: uid, client, access-token) in every request to a Rails Server.
Using Postman (http client) it's working.
With OkHttp (java http client) the headers just don't show up in the client (i've checked using Wireshark).
When i'm in debug mode it just work...
The additional headers with postman are due to postman sending an Origin header and the server is replying with CORS headers, i.e. Access-Control-.... These headers are send within the normal HTTP header, i.e. not after the response.
But these access control headers are only relevant when the access is done from a browser because they control the cross origin behavior of XHR. Since you are not inside a browser they should be irrelevant for what you are doing. What is relevant are the body of the response and some of the other headers and here you'll find no differences. Also irrelevant should be if multiple requests are send within the same TCP connection (HTTP keep-alive done by postman) or with multiple connections (OkHttp) because each request is independent from the other and using the same TCP connection is only a performance optimization.
If you really want to get these special headers you should add an Origin header within you OkHttp request. See the OkHttp examples on how to add your own headers. But like I said: these access control headers should be irrelevant for the real task and there should be no need to get to these headers.
There is a property "config.batch_request_buffer_throttle" in the file "config/initializers/devise_token_auth.rb" of the Rails Project. We changed it from 5 seconds to 0 seconds.
It is a property to keep the current token available for that amount of time to the following requests.
As the original documentation: "Sometimes it's necessary to make several requests to the API at the same time. In this case, each request in the batch will need to share the same auth token. This setting determines how far apart the requests can be while still using the same auth token."
So when we did the request using Postman or in Java Debug the 5 seconds was running allowing Devise to generate new tokens then retrieve them to the client.