Session Parameters

After a web surfing session has been recorded, the load test program can be generated .

Dynamic Session Parameters

However it is often desirable - or even required - that the recorded web surfing session must first be edited. Some possible cases are:

  • The web application contains HTML form-based authentication, and it is required that each user use an own username and password to login into the web application.
  • You wish to make a parameter of an URL call variable in order to set the value of the parameter each time before starting the load test. For example a booking date of a flight.
  • The recorded session contains dynamically-exchanged session parameters which must be extracted at run-time from the web pages, and then assigned to succeeding URL calls in order that the load test program runs successfully

All of these tasks, and many more, can be performed by using the "central variable handler menu", called Var Handler, which manages all dynamically- applied modifications to web surfing sessions. The process involves two steps:

  1. First a variable must be defined or extracted, and then
  2. The variable must be assigned

In other words, a variable must first be extracted before it can be assigned; however, some of the most commonly-used dialogs also support making automatic and/or global assignments. The process of extracting variables is completely independent from assignment; thus, many combinations are possible, providing maximum flexibility.

Variables can be extracted, by using the Web Admin GUI, from the following sources:

  • from Input Files, whose data are read at run-time during the load test
  • from HTML form parameters; for example, hidden form fields
  • from values of received XML and SOAP data
  • from values of received JSON data
  • from values of received Google Protobuf data
  • from CGI parameters contained in hyperlinks, form actions, or HTTP redirects
  • from any text fragments of received HTML and XML data
  • from User Input Fields - which are arbitrary configurable load test input parameters
  • from HTTP response header fields
  • from output parameters of Load Test Plugins

Additionally, it is also possible to define stand-alone variables which have constant or dynamic initial values .

A variable can be assigned as follows, irrespective of how it was extracted:

  • to the value of an HTML form field -
  • to the value of a CGI Parameter of a URL call
  • to values of XML and SOAP data of a URL call
  • to values of Google Protobuf data of a URL call
  • to a text fragment of a URL call (within the HTTP request header or the HTTP request content.
  • to the protocol (http/https), the host name or the TCP/IP port of one or all URL calls
  • to the user’s think time of a web page
  • to the response verification algorithm of a URL call (searched text fragment or size of received content.
  • to the number of iterations, and/or the pacing delay, of an inner loop F
  • to some HTTP request header fields (most request header fields are automatically handled by ZebraTester)
  • to an input parameter of a Load Test Plugin

Each variable has also a scope. Possible scopes are:

global all users will see the same value of the variable during the load test.
user although the variable has been defined only once, each user will see its own value during the load test. There are as many virtual instances of the variable as there are concurrent users used during the load test.
loop the variable is bound to the current loop (surf session repetition) of a user, and its value can change during each loop.
inner loop the variable is bound to an inner loop of a user, and can change its value during each iteration of the inner loop.

Although seemingly complicated, the Var Handler is a powerful tool which is easy to use. It is possible to satisfy complex requirements in a short period of time with a few mouse clicks, as described in the next sections. Programming knowledge is not required.

The variable handler can be invoked by clicking on any recorded URL call in the main menu. At the left side of the window, all details of the URL call which change from call to call are displayed. On the right side of the window, the Variable Handler is displayed and shows a summary of all extracted and assigned variables. This right hand side part of the window remains constant (static) for all URL calls:



Input Files can be used to extract variables from a text file, such as a username and a password per simulated user - which can be assigned to a login form. However the functionality of input files is generic which means that variables for any purposes can be extracted.

Click the Add File… button inside the Var Handler to define of a new Input File and enter a simple file name, without a directory path. Please note that this action creates only the definition of the input file, but that it does not create the input file itself on disk. This means that the input file must also exist on disk and that it must be placed inside the same Project Navigator directory where the load test program is stored.

You can create the input file on disk before, or during, or after the definition is made - or you can also copy an existing file to the corresponding Project Navigator directory.


Please note that the name of the input file should have the file extension *.txt (recommended) or *.dat .

The following options are available when defining an Input File:

File Scope - Defines the scope of the variables which will be (later) extracted from the Input File:

global (one-line): this scope is usually not useful for Input Files because only one line will be read during the entire load test, at the start of the test.

new line per user: a new line will be read for each simulated user during the load test. This is the proper scope for reading user account data (username / password). The line remains the same for all executed loops of the same user.

new line per loop: a new line will be read each time an simulated user executes a loop. The new lines are distributed over all users and loops.

NL per inner loop: a new line will be read each time an simulated user executes an inner loop. The new lines are distributed over all users, loops and inner loops.

Line Order - Controls whether the lines are read in sequential or randomized order.

Comment Tag - Defines a "start character" or a "start string" for commented-out lines. Such lines will be ignored during the load test.

Var Delimiter - Defines the "variable delimiter character", which separates values contained on the same line (several values/variables can be extracted from the same line).

Trim Extracted Values - Controls whether blank characters (white spaces) are removed from the start and the end of the extracted variables.

EOF Action - Controls the behavior when all lines from the Input File have already been read when a new line is requested:

reopen file - the file is re-opened. If a randomized line order was set, the lines continue to be randomly read in a new order.

stop load test

  • the load test will be immediately aborted. This option can be used to avoid duplicate logins with the same username / password in the case where fewer lines are available than users which should be simulated. Note that EOF can also become true for a randomized line order because the lines are first mixed during opening the file, and then read.

Next, you should test to ensure that the parsing of the Input File works correctly. This can be done by clicking button for an Input File definition:


Afterwards, you can extract variables from the Input File by clicking one or more times on the variable extractor icon:


Input Fields

Line Column # : the column number (of a line) from which the variable is extracted (1, 2, 3 ..)

Var Name: any new variable name, but with the following naming restrictions:

  • The name can only contain the characters A..Z, a..z, 0..9 and _ . Spaces are not permitted.
  • The name must not start with an underline character _

The following example shows the definition of an Input File, (first) without the assignment of variables:


The "read bars" with the title texts “password“ and “username“ are the names of the extracted variables. The variable scope is shown in brackets next to the title text.

The blue left arrow image

indicates that the value of the variable has been extracted. More details about how the variable was extracted can be displayed by clicking on the corresponding magnifier icon.

A variable, or the Input File definition itself, can be deleted by clicking on the red bar.

The Input File definition can be displayed and modified by clicking on the corresponding magnifier icon.

To finish this example, it is now necessary for the username and password to be assigned to the URL call which performs the login. All URL calls can be reviewed in the main menu. Click the corresponding URL to display the URL's "details menu" in which the assignment can be done. Alternatively - if you do not know on which URL the login was made - you can search for a specific text in the entire recorded session. In this example, you should use as the search string the password which was entered during recording. Click the Search button and enter the password as the search string:


Afterwards, click the red right-arrow inside the search result to see the URL details of the login.

Note: a red right arrow inside the search result means that the search string has been sent by a URL call to the web server. Blue left arrows inside the search result mean that the search text was found in a response to a URL call which was received from the web server.

After the login URL call has been found, the variables “username“ and “password” can be assigned to the form parameters (HTTP Request Content) by clicking on the corresponding icons.


Assignment Options

Assign from Var: select the variable which should be assigned.

*Var value conversion*
none the value of the variable will be assigned unchanged.
encode the value of the variable will first be URL-encoded and then assigned; for example, “Zürich HB“ will be transformed to “Z%FCrich+HB“. This is the appropriate option when the value of the variable may contain spaces or special characters.
decode this is the reverse of encode. This option is normally not used.

Assign var to all request parameters with same recorded value: by enabling this option, all URL calls in the recorded web surfing session are searched to see if any other URL calls use the same recorded value. If so, the variable will also be assigned to the other URL calls, resulting in the global replacement of recorded parameter values, irrespective of the parameter name.

After this, the complete extract and assignment definition appears as follows:


More Tips for using Input Files

Because the extraction of variables from Input Files is completely independent from their assignments, there are many other scenarios where Input Files are useful; for example:

  • Testing search forms, where the search text is read from the first variable of a line, and the response content test of the search result is compared to a second variable on the same line.
  • To set the emulated user’s "think time" variable on a per-user basis, or on a per-loop basis for each user.
  • To control the number of inner loop iterations.
  • To enter user-specific data into forms, such as an article number during a purchase transaction.

It is also possible to define several Input Files for the same load test program.

User Input Fields are arbitrary global variables whose values are requested each time a load test is started. The following example uses a User Input Field to make the host name of the URL calls variable, in order that the same load test program can be executed against a development system and a test system, without the need to record two web surfing sessions.



After the User Input Field has been defined, it can then be assigned to the host name (in this example). You can click on any recorded URL in the main menu which contains the "correct“ host name; that is, the host name which you want to make variable. Then click the assign button in the HTTP request header.


Input Fields

Assign to: whether the variable should be assigned to the protocol (http/https), to the host name, or to the TCP/IP port. In case you want to make more than one of these items variable, you must create additional User Input Fields.

Assign from Var: select the variable which was created when the User Input Field was defined.

Assign var to all requests with same protocol, host and port: when checked, the variable will be assigned to all URL calls which use the same protocol and the same host name and the same TCP/IP port.

It may be necessary to assign the host name again to https requests if you have recorded a session which uses both the http and https protocols within the same web surfing session.


The User Input Field will be displayed when the load test program is started. A maximum of 12 User Input Fields can be defined.


More Tips for using User Input Fields

User Input Fields are also often used to vary the “user’s think time". Another example would be the setting of the booking date for financial transactions.

Note: if you start a load test job optionally from a script (see Application Reference Manual), you must pass the User Input Field as an additional argument to the load test program. The name of the program argument is the name of the variable which was created when the User Input Field was defined; for example, for a variable named "hostname" the corresponding argument specification would be:

java PrxJob transmitClusterJob “Cluster 1“ Test01 -u 100 -d 300 -t 60 -nolog -hostname ““

Example - Adjustable User’s Think Time

The following example shows how the user’s think time of the page breaks (web pages) can be dynamically set every time when starting a load test:

  1. Create a User Input Field and set a default value (in this case in seconds)
  2. In the main menu, assign the variable of the User Input Field to the user’s think time of the first page break by using the option “Apply new user's think time values for all page breaks [2..n]”
  3. After that you can freely choose the user’s think time of the web pages every time when starting the load test. The value of the User Input Field is also shown in the load test result detail menu (test scenario).



ZebraTester Load Test Plugins are Extension Modules to the ZebraTester product. Plugins are configured using the GUI, and are executed during a Load Test. The following Plugins are already predefined and delivered as part of the ZebraTester installation:

Plugin Designation in the GUI Plugin Functionality
 Abort Failed Test  Aborts a running Load Test if too many errors occur within a configured time interval.
 Assign File Data to Request Content  Read the data of a file from disk and assign it to the request content of an URL call (only useful for HTTP/S POST requests and some WebDAV methods).
 Cookie Injector Sets a Cookie before, or during, the execution of a Load Test.
 Get Cookie Value Extracts the value of a Cookie into a GUI Variable. The extracted value can be later assigned to a CGI parameter of a succeeding HTTP/S Request (among other targets).
 Defer Load Test Start Delays the start of a Load Test Program for a configured time, expressed in minutes.
 Delay Full Load Limits the load - respectively the number of the simulated users - for a configurable time. After this time is elapsed the load is increased to the originally number of planned users.
 DNS Round Robin Load Balancing  Supports web servers which are using DNS Round Robin for load balancing. Deprecated: Replaced by integrated DNS options which can configured per test run.
 dynaTrace Integration Creates additional data during a Load Test for analysis using dynaTrace Diagnostics. The dynaTrace Integration Handbook contain further information about how to integrate ZebraTester with dynaTrace.
 Generic Output File During a Load Test, writes the values of up to 6 GUI Variables line-by-line to a text file. The file scope is freely configurable - lines can be written per virtual test user, per loop execution, or per URL call.
 Input File List Reads from a meta file a list of input files and assigns each simulated user a own input file. The simulated users are reading a new line from their input file each time before they are executing a new loop.
 Large Input File  Reads data from a large input file which has an unlimited size ( 1 GB)
 Large Response Content  Allows to receive response content data of a large size (up to 2 GB) for one or several URLs. Note that all response data are read as usual during load test execution, but that only a part of them are stored internally.
 Limit Response Content  Limit the receiving of response content data to a specified size. Further reading of data from the web server during load test execution is aborted (skipped) for the configured URL when the maximum size is reached.
 PKCS# 11 Security Device  Support for Smart Cards / PKCS# 11 Security Devices which contain a SSL Client Certificate used for authentication against web servers.
 Remove Cookie  Removes a cookie from the cookie store of a simulated user.
 User Synchronization Point  Retains all active users at a configurable synchronization point until all of the users have reached this point. After that, the users are rereleased, by applying a configurable deblock delay which is multiplied with the no. of the actual user (0, 1, 2 …).

The configuration of a Plugin, respectively adding a Plugin to a recorded web surfing session, can be done in the Var Handler:


Some Plugins require input parameters. Therefore it may be necessary to define additional variables. One option to define such variables is to create global visible stand-alone variables with constant initial values

  • in case that only constant values are required as Plugin input parameters . Of course, such additional variables can also be extracted from other sources, for example from Input Files, or User Input Fields, or from responses of previous URL calls.

The HTTP protocol by itself is stateless - there is no memory from URL call to URL call; however, most web applications require state information, such as the stage in a process that a user has reached - before login, after login, placed an order, and so on. Usually, cookies are used to keep state information. Cookies are set by the web server as additional HTTP response header fields, and sent by the web browser back to the web server, along with the HTTP requests of succeeding URL calls. This is normally not a problem because the correct handling of cookies is automatically done by the load test program.

However, some web applications use, as a special "session context", dynamically-generated CGI- or form-parameter values which are exchanged between the web application and the web browser in such a way that, if you repeat the same web surfing session, the values of these parameters are changed by a more or less random algorithm. If you use, during a load test, these "burned-in" values of dynamically-generated server-side CGI- or form-parameters, the load test will fail. A good example of this is the "__VIEWSTATE" parameter used by Microsoft web servers.

The solution to this problem is that the values of these dynamically-exchanged session parameters must be extracted at runtime (during the load test), and then assigned to the corresponding parameters of succeeding URL calls.

To make this task easier, ZebraTester provides the Var Finder menu. You can invoke the Var Finder either from the main menu, or from the Var Handler:


Automated Handling of Dynamically-Exchanged Session Parameters (Var Finder)

The Var Finder menu provides an overview of all URL request parameters, and their values, used anywhere in the entire recorded web surfing session. In this view, a parameter "name-value" pair is shown only once, even if the same "name-value" pair is used by more than one URL call. If the same

parameter(-name) is used with different values, it will be shown multiple times, once for each distinct value.

Proceed as follows:

  1. First, review the recorded values and try to judge which values could be dynamically-exchanged session parameters. If the value contains a long number, or is a cryptic hexadecimal string, the value has a good chance of being a dynamically- exchanged session parameter

In the example at left, levid, id and __VIEWSTATE are dynamically-exchanged session parameters. But type and “Status1:ins_step22:txtPolicyNumber” are not because their values have been entered manually into forms during the recording of the web surfing session..

  1. Try next to perform an automated handling of the dynamically-exchanged session parameters. This succeeds in approximately 50% of all cases.

To do this, click the x button at the left of the parameter name.

If you receive a success message, there is nothing more to do for this parameter:


The corresponding definitions inside the Var Handler are automatically created.

On the other hand, if you receive an error message, you must manually extract the value of the dynamically-exchanged session parameter (see the next subchapter):



In this example, the parameter __VIEWSTATE could be handled automatically, but the parameter id must be extracted manually. Since this parameter is listed twice - the same name with different values - the extraction must also be done twice, once for each distinct value.

Tip: you can use this menu as a checklist of parameters which are already dynamically handled, irrespective of whether the extraction done automatically or manually. The handling is already done if the line contains a blue (extract) arrow and a red (assign) arrow.

Manual Extraction of Dynamically-Exchanged Session Parameters

Note: Starting from ZebraTester Version 4.4-G a new function named Var Extractor Wizard had been added to the product.

If the automated handling did not succeed, you should click the magnifier button at the left of the desired parameter. All of the URLs in the web session are searched, looking for the recorded value.



Blue arrows pointing to the left indicate that the value of the parameter was found in a response received from the web server (HTTP response header or HTTP response content).

Red arrows pointing to the right indicate that the value of the parameter was found in a request which was sent to the web server (HTTP request header or HTTP request content).

You now need to extract the value from a response before it is sent the first time back to the web server. In this example, this must be done on item 19 (URL 19).

Important also is whether the value must be extracted from the HTTP response header (for example a 302 redirection with URL CGI parameters), or from the HTTP response content (for example HTML or XML data …). A helpful hint is displayed near the arrows (in this example: “Found in Response content”).

As can be seen in this example, the parameter must be extracted from URL 19 and assigned to the URLs 33, 35 and 38.

  • Click next on the first blue arrow

Then the URL Details / Var Handler menu is displayed:


Click the search button in the HTTP response content. The search results are marked in red.

Because automatic handling failed, you probably cannot extract the value by using the form parser (HTTP Response Content Forms Extract) , or by using the hyperlink parser (HTTP Response Content

Unique Hyperlinks Extract); therefore, you must use the text pattern-based token extractor.

Proceed as follows:

  1. Scroll left to the beginning of the line where the result is found, and memorize the line number (in this case 232)


  1. Locate a unique text pattern near the place where the variable text fragment (the search result) should be extracted. This text pattern can also be located on a preceding or succeeding line. Please note that the variable text fragment itself must not be part of the text pattern. If the text pattern is not on the same line as the text fragment to be extracted, you must also memorize the negative or positive line offset (.. -1, -2, +1, +2 ..)
  2. Mark the unique text pattern and click the var extractor



  1. Wait 3 seconds. The selected text pattern will be copied into the Var Handler input form (field Search Text). At this point, if a negative or positive line offset is needed, select the line offset in the field Extract Var on.


Now try clicking on Test Extract in the Var Handler input form, and check to see if the value of “Extracted on Line” has the same line number within the HTTP response content as the line number where the variable text fragment (the result) should be extracted. If the line numbers are not identical, your “unique text pattern” is not unique, and you will have to find another text pattern.

  1. Inspect the HTTP response content for the preceding and succeeding characters which bracket the variable text fragment. In this example, these characters are r and .


 Enter these characters into the field **Token Delimiters**. After this, click again on **Test Extract** and then click the blue question mark **?**


At this point, a pop-up window is displayed which shows a list of text fragments (tokens). Enter the number of the token containing the desired variable text fragment into the field Extract Token Nr, and then click again on Test Extract.


Check to see if the blue marked value is exactly the same as the recorded value of the parameter which should be extracted; that is, if it is the same as the variable test fragment / search result.

  1. Finally, enter an arbitrary variable name into the field Map to Var Name. In this example, the name id_1 is chosen because the parameter must be extracted twice, once each into two different variables, as was shown in the Var Finder. Activate the checkbox Assign var to all request parameter with same recorded value, and let the checkbox Try URL-Encoding remain activated. Then click on Extract.


The configuration inside the Var Handler now shows that the value of the parameter is extracted from URL 19, and assigned to the URLs 33, 35 and 38. This matches exactly with the first estimate, which was made by clicking on the magnifier icon inside the Var Finder.

Tip: in this example you would have to repeat the same steps to handle the second value of the parameter id. It is recommended that you save the recorded web surfing session periodically after making changes inside the Var Handler.

Further Tips

Dynamically-Exchanged Session Parameters can also be extracted in an easy way from redirections, from forms, and from hyperlinks:


ou should always use the option “Assign var automatically to all HTTP requests which contain form or CGI parameters with the same recorded valueimage




The Search Overall menu gives you an excellent overview if you know already the name or the value of a Dynamically-Exchanged Session Parameter. Thus it is easy to determine the first URL from which the session parameter should be extracted:

Paste the value or the name of the session parameter into the input field and extract it from the response in which the first occurrence is found.

In rare cases, the name of an HTTP request parameter is variable, instead of the parameter value being variable. Even rarer are cases where a file path of a URL call contains variable parts.

You can handle such cases as follows:


Use the text pattern-based variable extractor.

  1. At the last step, use the checkbox Assign var to all matching request file and request content patterns with same recorded value, instead of Assign var to all request parameter with same recorded value.

There are also other rare cases in which a text pattern must be extracted from an HTTP response header because a variable HTTP redirection occurs, on which only a part of the URL file path, or a part of a CGI parameter, is variable. This is also supported - if two extractor icons are present, you simply use the second one.


Extracting and Assigning Values of XML and SOAP Data


In case that XML or SOAP data have been recorded, ZebraTestet parses such data automatically and displays an additional XML Icon within the title of the “HTTP response Content” and the “HTTP request content” box:



If a recorded web surfing sessions contain HTTP file uploads, you can also use a variable for each file upload which allows to select the uploaded file dynamically during the load test. Such a variable is often extracted from an input file whose lines contain different file names (without file paths).


Note: before you start the load test, you have to place all files which should be uploaded into the same project navigator directory where the compiled load test program resides. Then - before you start the load test - you have to zip the compiled *.class of the load test program together with all files which should be uploaded (and also together with all used input files). After this execute the zipped archive itself as load test program.


The following illustration is not exhaustive.



Variables are usually defined implicitly by creating Input Files, User Input Fields, using the Var Finder, or by extracting values using the Var Handler. However, it is also possible to define variables directly for special-purpose use. Depending on the scope, directly-defined variables can have special initial values which are set during the load test by the load test program itself.

Supported combinations of scope and initial values are:

Initial Value global var user var loop var inner loop var
constant value x x x x
null x x x x
current user counter - x x x
loop counter - -
inner loop counter - - - x
system time milliseconds x x x x
load source IP host name x   x³ -
load source IP address x   x³ -

¹ = (outer) loop counter over all users

² = (outer) loop counter of the user

³ = inclusive multi-homing support

Initial Values:

constant value the variable is initialized with an arbitrary constant value.
null the value of the variable is not valid / undefined at initialization time.
current user counter the variable is initialized with the sequence number of the simulated user (0, 1, 2 ..).
loop counter global var scope - the variable is initialized with the outer loop counter (0, 1, 2 ..) - counted over all simulated user / user var scope: the variable is initialized with the outer loop counter of the actual simulated user (0, 1, 2 ..).
inner loop counter the variable is initialized with the iteration counter of the inner loop (0, 1, 2 ..) - of the actual simulated user.
system time milliseconds the variable is initialized with the current operating system time, in milliseconds since 1970.
load source IP host name the variable is initialized with the Exec Agent host name.
load source IP address the variable is initialized with the Exec Agent IP address.

A Java (J2EE) application server can be configured by the developers of the web application such that a procedure called "URL rewriting" is used to build the session context, instead of using session cookies. In this case, the server will assign at runtime a special dynamic session parameter to every returned hyperlink, and to every form, which contains the session context.

An example of a hyperlink with applied URL rewriting is as follows:

<a href=";jsessionid=bu3fy0bbj1?currentDir=344">forward</a>

The URL rewriting parameter is appended to the URL file path, separated by a semicolon, and appears before the normal CGI parameters which start with a question mark.

Usually a Java application server supports both session cookies and URL rewriting; however, only one of these procedures is applied, on a per-user basis, to build the session context. The inner algorithm of the application server works as follows:

  1. When a web browser requests any page from the server for the first time, the server does not know if the web browser supports session cookies. For this reason, the server sends a session cookie to web the browser and performs additionally URL rewriting for all hyperlinks and forms for the first web page.
  2. When the web browser requests a second page from the server, and transmits the received session cookie back to the server, the server will then know that the browser supports cookies. For the current and all succeeding web pages, URL rewriting will no longer be done.
  3. If on the second page request, the web browser does not send back the cookie, or if the application server is configured to disable the use of session cookies (in which case an initial cookie will not have been sent anyway), the web server notes the absence of the session cookie and does URL rewriting for the current web page, and all succeeding web pages.


You do not usually have to do anything special in this case because most Java application servers support session cookies. However, if session cookies are disabled, you must first enable the support of URL rewriting inside the Var Handler before the load test can be executed successfully. You will recognize the need for this when you review the recorded URLs in the main menu - if the URL rewriting parameter is found in all URL calls in the majority of web pages, you will have to enable URL rewriting support in the Var Handler.

To do this, proceed as follows:

  1. Choose any URL detail menu
  2. Click the URL rewrite button in the Var Handler
  3. Enter the name of the URL rewriting parameter in the field Rewrite Parameter
  4. Enter an arbitrary variable name in the field Map to Var Name
  5. Use the option automatically for the field Dynamic Handling

After URL rewriting has been enabled, the Var Handler shows only the first extraction of the URL rewriting parameter - but not its assignment. This is normal behavior because the assignment in succeeding URL calls will be done automatically later in the load test, without the need for additional configuration.


Note: the URL rewriting parameter may also have a name other than jsessionid because the name itself can be configured inside the web application server. You must enter the actual parameter name in the field Rewrite Parameter.

It is also possible that the value of the URL rewriting parameter can change during the web surfing session; for example, after logging in to the web application, or after logging out. In this case, you will see two or more extractors for the URL rewriting parameter inside the Var Handler.