I would like to continue writing about the methods used to pass various data between the client and server part of a web application. In the previous post I briefly described the cookies mechanism used to join the successive requests of the same user into a consistent session. The basic concept is that the server sends a cookie to the client and the client attaches it as a key to all subsequent requests sent to that server.
In fact, the same concept is often used without cookies or in addition to them. Why is this needed? One reason is that for security reasons some users can disable cookies support in their browsers. Another reason is that it is not always sufficient to identify only the user session.
For example, imagine that our application provides access to a database containing personal data of 1000 people. We want to find some “John Smith” and change, say, his status from “Married” to “Single”. Probably our web application has a search capability. When we apply it, it finds John Smith and shows his data to us using a web form. We make the change and click the “Update” button. As a result our browser creates a POST request that contains the values of all the form fields. When server receives that request, it updates the database.
However to do this it will not search the database for “John Smith” again. This is not the right way to work with a database, because there may be many people with the same name. The right way is to use some ID which is unique for each database record. When we initially made the search, the server found a record in the database and sent all its data (including that ID) to the client. We did not see the ID in the browser, because it did not contain any useful information for a human reader. However when we submitted the changed form, that value was passed to the server along with all the other form fields. When the server received the POST request, it did not need to search the database again, because it received the record ID along with all the other data, so it just updated the specified record.
Now let’s see how this is done in practice. Our web form HTML code could look like this:
<html> <body> <form action="http://www.mysite.com/form_handler.php" method="post"> Name: <input name="user" type="text" value="John Smith" /> <br> Status: <select name="status"> <option value="s"> Single </option> <option selected value="m"> Married </option> </select> <br> <br> <input name="record_id" type="hidden" value="1234567890" /> <input type="submit" value="Update" /> </form> </body> </html>
When the above form is rendered in a browser, it is shown like this:
Note that the field named “record_id” is marked in the HTML code as hidden. Such fields are ignored when a visual representation is created. However they are submitted to the server along with all the other data. When we change the status to “Single” and click the “Update” button, the following request is sent to the server:
POST /form_handler.php HTTP/1.1 Content-Type: application/x-www-form-urlencoded user=John+Smith&age=30&status=s&record_id=1234567890
Why all the above is important for load testing? The values of hidden parameters can be different for each user session, because they are provided by server. This means that when we create many sessions from the initially recorded template, we need to make sure that such values are extracted from server responses and passed as parameters of subsequent requests. Fortunately, most load testing tools, such as WAPT, can do this automatically. In the next post I will describe how it is done.