POST pages

A POST page is a page that processes the submit of a HTML form. Not all HTML forms submit to a POST page, some submit to a GET page (where field data is sent in the URL). If you can change your form to submit the data via GET then you can easily fix this issue without needing the fix below.

How ClickTale handles POST pages
By default ClickTale doesn't support caching HTML content of POST pages. This is by design to prevent "double submits" of your forms and to eliminate potential side-effects.

Normally what would happen is that ClickTale will record all the client side activity correctly but the caching of the HTML content will fail. As a result you might see one of the following symptoms: This happens because when ClickTale attempts to cache the page it will do a regular GET request to your server, expecting to get an answer. You, however, will be expecting the parameters from the form and will be willing to take some action such as adding something to the database or sending an email.
 * An error dialog during playback, there will usually be a yellow exclamation icon near the row of the recording.
 * A blank playback frame.
 * Wrong content shown in playback frame.

Possible solutions
There are several possible solutions:
 * The easiest solution is to process the POST and then redirect to a GET URL.
 * Redirect the user to another page once POST processing ends. That page will be a GET page so no caching of POST pages will be required.
 * Install one of our ClickTale Integration Modules. Currently there are ones for ASP.NET, PHP, J2EE Integration Module and Ruby On Rails (ROR).
 * Change your FORM to use the GET method. This is only good if your form does no processing that includes additional actions, such as creating records, accounts or sending emails. The GET method is only good for forms with a small number of simple fields, as field values will be shown in the URL and the URL length is limited to 2,048 characters.
 * Change your POST processing page to redirect to a GET page once processing is done. This is instead of rendering the success/error information in the POST processing page. Great option for "thank you for..." pages, etc'.
 * Create a static HTML page that contains the same content of the POST page and use the ClickTaleFetchFrom instruction to make ClickTale fetch the page from that location. Minor differences between the static HTML page and the actual content are OK.
 * Use the ClickTaleUploadPage API method. This is good for short pages.
 * Implement custom handling in your code to support your specific design (See below).

Implement custom handling in your code - an example
We can modify our POST script to support caching as follows. This is the most efficient method but will also require the most effort to implement. We will continue this tutorial by explaining how to implement this option.

On our public site (www.clicktale.com) we have a signup form. When people submit the form it is sent as a POST request to us. We have an ASP.NET page that processes this form. All examples will be in ASP.NET but you can easily adapt them to your own needs. The back-end script is called signup.aspx and after finishing the processing it can return 5 different responses to the visitor. We will:
 * 1) Extend the script to return any of the possible responses based on a GET parameter without doing any processing.
 * 2) Extend the script to instruct ClickTale which version of the page to request based on what was returned to the user.

Prior to this, the script was checking if the request is a POST request and doing some processing. If the request was not a POST request it would redirect to the original form. We will add an additional case so if the query string parameter "p" is present then we will do some rendering. "p" just tells us which of the five panels to show. You may use more than one parameter or use different parameter names if you would like. For each value of "p" we return a different response by making one panel visible.

Now we need to tell ClickTale to request a URL of your script with the right parameter for each of those cases. Normally our panels look like this: Now we can modify them to include an assignment of a custom caching URL (a property from the API) We do this for each of the panels. Important: ClickTale external script file (WR[ver].js) should be included prior to the assignment and the call to ClickTale(...) function should be included after the assignment.

After those two modifications, the visitor will get the response from the back-end script and instruct ClickTale to do the caching from the correct location. ClickTale will then request the page from the alternate location and your server will respond with the correct content. Now your playback will show the correct data.

* Additional relevant APIs - ClickTaleRegisterForm APIs