I would like to know the Application of Pre-Processor and Post-Processor in JMeter.
As name suggests these components are used to process something (request, response, custom operations) before and after the sampler (request).
Pre processors :
These components are used before the request to perform custom actions.
Ex:
Suppose If I want to add something to request before sending it to server then preprocessor is added. For example if could be fetching some information from DB or Regex operations. Thus after performing those operation we can pass results of these actions to request. Thus we can modify/update request or request parameters before sending request to server.
Post processors :
These components are used after the response of request has arrived to perform custom actions.
Ex:
Suppose If I have asked for something on google and I want to find out something from response for below actions,
To validate response
Extract something and process to pass data to next request
Perform custom actions like DB operations, file operations etc.
Then post processors can be used.
See above snapshot,
Components pointed by arrow will be executed before request is sent to server and components within square will be executed after response has arrived.
I hope this was helpful.
Pre Processors are designed to provide any setup actions required for the test sample like generate some unique test data or amend parent sampler dynamically
Post-Processors are designed to tear down the sampler, or most commonly to extract "interesting" bits from response for later re-use (this is called "correlation")
Pre and Post Processors execution time isn't included into test reports. If you want to change this behavior you need to use Transaction Controller
Related
We have a URL https://www.mylink.com/est?myId=4d22b9d0-4ff2-46c3-9343-945304dfea93
The above request also contains post data:
myId=4d22b9d0-4ff2-46c3-9343-945304dfea93
How can I parameterize this as the url and post data both contain same value but its dynamic. Also, how may I store it in a variable to use it somewhere else as well?
In order to be able to use it in URL and request body you need to extract it somewhere somehow, this dynamic ID is probably associated with this or that user account so my expectation is that after logging in you should see this ID somewhere in the response.
The process is known as correlation and there is a plenty of information over the web about handling dynamic requests in JMeter. There are also solutions which provide semi or fully automated correlation of the dynamic parameters like Correlations Recorder Plugin for JMeter or JMeter Proxy Recorder
If you just need to generate an unique GUID-like structure - you can do it using __UUID() function
As we all know, file uploading is most often accomplished using POST method. So, why can't the GET method be used for file uploads instead? Is there a specific prohibition against HTTP GET uploads?
GET requests may contain an entity body
RFC 2616 does not prevent an entity body as part of a GET request. This is often misunderstood because PHP muddies the waters with its poorly-named $_GET superglobal. $_GET technically has nothing to do with the HTTP GET request method -- it's nothing more than a key-value list of url-encoded parameters from the request URI query string. You can access the $_GET array even if the request was made via POST/PUT/etc. Weird, right? Not a very good abstraction, is it?
Why a GET entity body is a bad idea
So what does the spec say about the GET method ... well:
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe."
So the important thing with GET is to make sure any GET request is safe. Still, the prohibition is
only "SHOULD NOT" ... technically HTTP still allows a GET requests to result in an action that isn't
strictly based around "retrieval."
Of course, from a semantic standpoint using a method named GET to perform an action other than
"getting" a resource doesn't make very much sense either.
When a GET entity body is flat-out wrong
Regarding idempotence, the spec says:
Methods can also have the property of "idempotence" in that (aside from error or expiration issues)
the side-effects of N > 0 identical requests is the same as for a single request. The methods GET,
HEAD, PUT and DELETE share this property.
This means that a GET method must not have differing side-effects for multiple requests for the
same resource. So, regardless of the entity body present as part of a GET request, the side-effects
must always be the same. In layman's terms this means that if you send a GET with an entity body
100 times the server cannot create 100 new resources. Whether sent once or 100 times the request must
have the same result. This severely limits the usefulness of the GET method for sending entity bodies.
When in doubt, always fall back to the safety/idempotence tests when evaluating the efficacy
of a method and its resulting side-effects.
In case of GET Method
Appends form-data into the URL in name/value pairs and length of URL is limited(3000 characters).
File content can't be put inside a URL parameter using a form.So use POST
In Get method, the value of action, appends a `?' to it, then appends the form data set, encoded using the "application/x-www-form-urlencoded" content type. The user agent then traverses the link to this URI. In this scenario, form data are restricted to ASCII codes.
So, that file upload is not possible in GET Method
Shouldn't PUT be used to Create and POST used to Update since PUT is idempotent.
That way multiple PUTs for the same Order will place only one Order?
The difference is that a PUT is for a known resource, and therefor used for updating, as stated here in rfc2616.
The fundamental difference between the POST and PUT requests is
reflected in the different meaning of the Request-URI. The URI in a
POST request identifies the resource that will handle the enclosed
entity. That resource might be a data-accepting process, a gateway to
some other protocol, or a separate entity that accepts annotations. In
contrast, the URI in a PUT request identifies the entity enclosed with
the request -- the user agent knows what URI is intended and the
server MUST NOT attempt to apply the request to some other resource.
I do see where you are coming from based on the names themselves however.
I usually look at POST as it should be the URI that will handle the content of my request (in most cases the params as form values) and thus creating a new resource, and PUT as the URI which is the subject of my request (/users/1234), a resource which already exists.
I believe the nomenclature goes back a long ways, consider the early web. One might want to POST their message to a message board, and then PUT additional content into their message at a later date.
There's no strict correspondence between HTTP methods and CRUD. This is a convention adopted by some frameworks, but it has nothing to do with REST constraints.
A PUT request asks the server to replace whatever is at the given URI with the enclosed representation, completely ignoring the current contents. A good analogy is the mv command in a shell. It creates the new file at the destination if it doesn't exist, or replaces whatever exists. In either case, it completely ignores whatever is in there. You can use this to create, but also to update something, as long as you're sending a complete representation.
POST asks the target resource to process the payload according to predefined rules, so it's the method to use for any operation that isn't already standardized by the HTTP protocol. This means a POST can do anything you want, as long as you're not duplicating functionality from other method -- for instance, using POST for retrieval when you should be using GET -- and you document it properly.
So, you can use both for create and update, depending on the exact circumstances, but with PUT you must have consistent semantics for everything in your API and you can't make partial updates, and with POST you can do anything you want, as long as you document how exactly it works.
PUT should be used for creates if and only if possible URI of the new resource is known for a client. New URI maybe advertised by the service in resource representation. For example service may provide with some kind of submit form and specify action URI on it which can be a pre populated URI of the new resource. In this case yes, if initial PUT request successfully creates resource following PUT request will only replace it.
It's ok to use POST for updates, it was never said that POST is for "create" operations only.
You are trying to correlate CRUD to HTTP, and that doesn't work. The philosophy of HTTP is different, and does not natively correspond to CRUD. The confusion arises because of REST; which does correspond to CRUD. REST uses HTTP, but with additional constraints upon what is allowed. I've prepared this Q & A to explain the HTTP approach to things:
What's being requested?
A POST requests an action upon a collection.
A PUT requests the placement of a resource into a collection.
What kind of object is named in the URI?
The URI of a POST identifies a collection.
The URI of a PUT identifies a resource (within a collection).
How is the object specified in the URI, for POST and PUT respectively?
/collectionId
/collectionId/resourceId
How much freedom does the HTTP protocol grant the collection?
With a POST, the collection is in control.
With a PUT, the requestor is in control (unless request fails).
What guarantees does the HTTP protocol make?
With a POST, the HTTP protocol does not define what is supposed to happen with the collection; the rfc states that the server should "process ... the request according to the [collection's] own specific semantics." (FYI: The rfc uses the confusing phrase "target resource" to mean "collection".) It is up to the server to decide upon a contract that defines what a POST will do.
With a PUT, the HTTP protocol requires that a response of "success" must guarantee that the collection now contains a resource with the ID and content specified by the request.
Can the operation result in the creation of a new resource within the collection?
Yes, or no, depending upon the contract. If the contract is a REST protocol, then insertion is required. When a POST creates a new resource, the response will be 201.
Yes, but that means the requestor is specifying the new ID. This is fine for bulletin boards, but problematic with databases. (Hence, for database applications, PUT will generally not insert, but only update.) When a PUT creates a new resource, the response will be 201.
Is the operation idempotent?
A POST is generally not idempotent. (The server can offer any contract it wishes, but idempotency is generally not part of that contract).
A PUT is required to be idempotent. (The state of the identified resource is idempotent. Side effects outside of that resource are allowed.)
Here is the rfc:
https://www.rfc-editor.org/rfc/rfc7231#section-4.3.3
It depends..
you can create/update sites/records with both.
When the client is specifying the URI then PUT is the way to go.
e.g. Any Code Editor like Dreamweaver, PUT is the right protocol to use.
have also a look at this thread: put vs post in rest
In Kohana 3.1.x framework.
What are the benefits to send data with internal requests like this
$post = Request::factory('module/data')
->method(Request::POST)
->post(array('some' => 'random data'))
->execute()
->response;
if you could simply send data like this
Module::instance()->data(array('some' => 'random data'));
In this example Module is a random module and data is some random method.
I'll call this Module via ajax and internal requests. I'm planning to design RESTful API.
QUESTION IS: Why use HMVC instead of just directly using an internal class API
Because they're internal requests, there is no additional HTTP request being made.
You might want to take a look at Request_Client_Internal and compare it to Request_Client_External. After that you should feel enlightened :)
Edit:
You should know that AJAX requests aren't the only "external HTTP requests". cURL, PECL HTTP, file_get_contents() and other PHP functions will also send an external HTTP request (imho you should read the RFC 2616 to understand how HTTP actually works).
With HMVC calls you can use the same controller for both Ajax and internal requests. Also, it can handle a standard (non-ajax) http-requests, form submits for example. All-in-one solution, single entry point.
If you dont want HMVC calls, you will require one call for internal request (somewhere in base controller) and another one - in a special Ajax controller. Also you may have a problems with a data rendering (usually HMVC and ajax calls are using different templates). Its not DRY.
I would comment on the above, what biakaveron said, but I can't yet, so I put it as an answer.
#stacknoob: Could you use Module::instance()->data(array(...)) as controller's action? You could - with some extra code.
Instead, what biakaveron already said, you can keep your code logic and have the action return the same result for AJAX and HMVC requests. In one place. DRY + KISS.
I completely understand the differences between the two in terms of form handling, user discretion and privacy of data, but in what situation would anyone rather use GET over POST when sending form results?
Thanks
W3C HTML 4.01 Recommendation on the appropriate usage of GET and POST:
The "get" method should be used when the form is idempotent (i.e., causes no side-effects). Many database searches have no visible side-effects and make ideal applications for the "get" method.
If the service associated with the processing of a form causes side effects (for example, if the form modifies a database or subscription to a service), the "post" method should be used.
Note: The "get" method restricts form data set values to ASCII characters. Only the "post" method (with enctype="multipart/form-data") is specified to cover the entire [ISO10646] character set.
GET places parameters in the URL itself, allowing everyone to see. While POST would be ideal for logins and security-sensitive data, GET is ideal when you want a dynamic page to be bookmarked.
Take a forum for example. The thread which shows all posts within it is loaded dynamically. There doesn't exist a page for every thread available, meaning parameters must be provided which indicate which thread to load. These parameters are passed using GET so that you can bookmark the page and that exact URL with the parameters provided will be used again to load the page.
For instance, to make form data visible in logs.
If i need that user can save a bookmark of next step/page (for whatever reason) i would use GET other than that probably POST.
Both are unsafe and you must escape both.