Applies To:

Show Versions Show Versions

Manual Chapter: FirePass Controller Administrator Guide: 13 - Using Web Applications Engine Trace
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


13

Using Web Applications Engine Trace


Understanding Web Applications engine trace

The FirePass controller Web Applications engine trace feature provides an easy way for you to capture logs of user sessions through the Web Applications feature of Portal Access. You can use the trace feature when a user has trouble using a web applications favorite or direct connection. The logs provide detailed information about how the FirePass controller is altering the data stream.

Situations when you would use the Web Applications engine trace feature include the following:

  • A web page does not display properly on a client computer when the user accesses the application through a FirePass controller Portal Access connection, but the web page does display correctly when the user accesses the application in another way.
  • Java or JavaScript does not work on a client computer when the user accesses the application through a FirePass controller Portal Access connection, but Java or JavaScript normally does work when the user accesses the application in another.
  • Non-HTML elements on a web page do not work on a client computer when the user accesses the application through a FirePass controller Portal Access connection, and the non-HTML elements might or might not normally work when the user accesses the application in another way.
    For example, a web page might include XML, Flash, or ActiveX components that prevent a client computer from accessing the page.

Using the Web Applications engine trace feature

The trace feature creates logs that you can use to help identify the causes of problems with web pages.

Note

If you plan to send the logs to F5 Networks Technical Support, open the logs in a text editor, review them, and delete passwords and sensitive information. For more information about reviewing Web Applications engine trace logs, see Analyzing Web Applications engine traces .
Important

Dynamic caching on the FirePass controller must be disabled when using the Web Applications engine trace, unless you are troubleshooting a problem with the dynamic cache. If dynamic caching is not disabled, items that are served out of the cache are not included in the backend trace and you will be unable to compare the response received from the backend to the response sent to the client. You should also ask the user to clear the browser cache first, unless the problem occurs only when content is already cached by the browser.

To use the Web Applications engine trace

  1. Have the user who is experiencing problems log on to the controller, but do not have the user access the problematic web application yet.
  2. Connect to the FirePass controller's Administrative Console using a web browser, and log on.
    The Device Management Welcome screen displays.
  3. In the navigation pane, click Device Management, expand Maintenance, and click Troubleshooting Tools.
    The Troubleshooting Tools screen displays.
  4. In the User box in the Web Applications engine trace area, type the user's name whose session you want to trace.
  5. To get a list of active sessions for the user, click Get user sessions.
    The user's session ID and status information display in the table.
  6. Begin the trace operation by clicking the Connect link that is associated with the user session.
    The trace begins, and the Connect link changes to a Download link.
  7. Have the user start a Web Application session and navigate to the web page that manifests the problem.
  8. After the user experiences the problem and the page finishes loading, click Download, and save the trace file to your local hard drive.
  9. Note: If the web page does not fully load, the trace file may be empty. To capture content, be sure to connect to the user session, then have the user perform the actions you want to trace, and wait for the user's browser to finish loading the content or time out.

Understanding trace files

The Web Applications engine trace creates a zipped file with a default name of ur_debug.zip. Table 13.1 lists the files contained in the zipped file.

Table 13.1 Contents of the Web Applications engine trace .zip file
File name
Contents
<nnn>.log
Messages from the web applications modules on the FirePass controller itself.
Content in these files is intended for use by F5 Networks Technical Support, and probably is of limited value for non-F5 personnel.
backend_<nnnn>.html
Messages representing the request and response exchange between the FirePass controller and the web server containing the request for the page, and the content before web applications engine parses the content.
backend_<nnnn>.(gif | jpg | ...)
Images referenced in the associated backend_<nnnn>.html file, received by the FirePass controller from the application's web server.
frontend_<nnnn>.html
Messages representing the request and response exchange between the FirePass controller and the client requesting the page.
This is the data from the application's web server accessed by the user session, after the FirePass controller has processed it and added state-change information.
frontend_<nnnn>.(gif | jpg | ...)
Images referenced in the associated frontend_<nnnn>.html file, sent to the client by the FirePass controller.
https.extra-error_log
 
index.html
Content that formats the data for presentation in a browser window. Each file represents one specific client request.
The .zip file contains one summary index.html, and one index.html file representing each client request in the trace. After extraction, you can find the summary file in the root extraction directory, and each client-request specific file in its associated directory.
list.html
Content representing each client request in the trace.
The web applications trace engine generates the content of this file during the active trace operation.
log.html
Data that the content processing engine and content processing scripts changed.
This is a commented list of the reverse-proxy actions the FirePass controller performed on the associated client request.
ur_debug.log
This is a flag file and it is always empty.

Extracting these files results in a directory structure that contains a summary index.html and the list.html at the top, with each client request extracted into a unique directory, named using a sequence number assigned by Web Applications engine trace. For example:

  • REQ_00000000
  • REQ_00000001
  • ... REQ_nnnnnnnn

where nnnnnnnn represents the number of client requests recorded in the web trace.

At a minimum, each client request directory contains the following files:

  • backend<nnnn>.html
  • frontend<nnnn>.html
  • index.html
  • log.html

Each of the files in the client request directory is associated with one specific client request.

The browser loads these files into different frames in the window, depending on how you open the files. For more information, see Analyzing Web Applications engine traces .

Analyzing Web Applications engine traces

The files created by the Web Applications engine trace contain data you can look at using a web browser. Many of the files contain only unreadable code or image data, but one or more should contain content that might help in troubleshooting issues. For example, you can debug a connection problem by comparing the backend<nnnn>.html file (data coming into the FirePass controller from the accessed web server) and the frontend<nnnn>.html file (the same data after the FirePass controller has processed it), locating the place at which processing fails, and repairing it.

When you open the summary index.html file (the index.html file in the top-level directory), the browser loads list.html into the top frame of the browser window. Then, depending on which link you select in the top frame, the browser loads the associated files into the appropriate frame in the browser window.

When you open an index.html that resides in a client-request directory, the browser loads the associated files into the appropriate frame in the browser directory.

  • Loads log.html into the top frame
    If you are viewing the window from the summary index.html, the browser loads log.html in the second horizontal frame.
  • Loads frontend<nnnn>.html into the lower-left frame
  • Loads backend<nnnn>.html into the lower-right frame

For more information about the extracted Web Applications engine trace files, see Understanding trace files .

You can also open these files in any text editor.

Tip


We recommend using Internet Explorer as the browser because it shows data with additional highlighting that can help you as you debug the problem.

To compare trace file content

The FirePass controller processing converts all URLs and anchor tags. Processed URLs contain the host name of the FirePass controller, as well as converted paths. The paths are converted to hide their true locations. A converted path starts with f5-w-. If you are running the reverse proxy in compatibility mode, the converted path starts with i-tr-.

  1. Open the summary index.html or an index.html that resides in a client-request directory.
  2. Compare the incoming data (the backend<nnnn>.html file) with the processed data (frontend<nnnn>.html), focusing on URLs and anchor tags (<a href=...>).
  3. Find the point at which the FirePass controller stops processing URLs or paths.
    The problematic code usually exists immediately prior to this point.

Once you have made this comparison, and located the point where controller processing stops, you can use this information to find and fix several types of problems.

Fixing common problems

If you are able to identify the place in the trace where the problem occurs, you may be able to fix the problem.

Most problems are caused by one of three things:

Fixing HTML syntax errors

HTML syntax errors are common. Frequently they are invisible or cause only minor problems with a web page's appearance, but web pages with syntax errors can also result in significant problems in certain browsers or when accessed through a Portal Access favorite.

To find HTML syntax errors

  1. Start with the comparison you made of the frontend<nnnn>.html and backend<nnnn>.html in Analyzing Web Applications engine traces , preceding, locating the point at which the FirePass controller stopped converting the URLs.
  2. Look at the HTML source code immediately preceding the error point.
    This is where you find HTML syntax errors that can cause problems.

If you find an HTML syntax error, you can correct it in one of several ways:

Fixing HTML syntax errors by editing the source HTML

The easiest way to fix HTML syntax errors is to correct them on the web page at its source. To do this you need access to the web server and the source web pages. If you have this access, correct the error directly on the page.

Errors include:

  • Missing quotation marks
  • Doubled quotation marks
  • Tags that have no corresponding close tag

Using the Web Applications content cleaning feature to fix HTML syntax errors

If you cannot correct the syntax error on the source HTML page, you can use the FirePass controller content cleaning feature to fix the syntax error. The content cleaning feature only works on HTML and plain text.

To use the content cleaning utility

  1. In the navigation pane, click Portal Access, and click Content Processing.
    The Content Processing screen opens with the Preprocessing Scripts tab selected.
  2. In the Web Applications Content Cleaning area, type the URL for the page that contains the HTML syntax error.
    You can specify a comma-separated list of URLs to process for content cleaning. You can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character. An empty list means that the content cleaning functionality does not clean any content.
  3. Click Update.
    The URL's patterns are saved.
  4. To verify that the cleaning utility worked, compare front-end response files from before and after using the cleaning utility.

Tip


For a faster way to test content cleaning, type the complete URL of the web application page into the text field under Test Content Processing Settings, and click the Test button. This runs content cleaning on the page, and returns four pieces of data: original URL source, content cleaning warnings and errors, modified URL source, and modified URL source difference.

Using Web Applications content processing scripts to fix HTML syntax errors

If the problem continues after you use the content cleaning feature, you can create a SED script to fix specific HTML errors dynamically. SED is a scripting language that you can use to locate a pattern in an incoming web page, and modify the match before sending the web page to the client. For more information about content processing, see Configuring processing scripts for content processing, in Chapter 7 , and Adding a SED script, in Chapter 7 .

Note

The web applications module processes the list of content processing scripts until it finds a match. After that, it stops examining scripts. To replace several things on one page, you must replace all content in a single content processing script.

To fix an HTML error using a SED script

  1. In the navigation pane, click Portal Access, and click Content Processing.
    The Content Processing screen opens with the Preprocessing Scripts tab selected.
  2. In the Web Applications Content Processing Scripts area, click Add New Favorite to add a new SED script.
    The editing fields for the SED script display.
  3. In the Processing script name box, type a name that identifies the script.
  4. In the URL match patterns box, type a URL for the web page that is causing problems.
    You can specify a comma-separated list of URLs to process for content processing. You can use the wildcard characters asterisk (*), which represents many characters, and question mark ( ? ), which represents a single character, for example, http://*.siterequest.com/*. An empty list means that the content processing functionality does not process any content.
  5. If you want your script to process content other than text-based (plain text, HTML), type the additional content type in the Content Type box. For example, you could type application/javascript.
    An empty field indicates a text file.
  6. In the Sed processing script box, type the script.
  7. From the Processing list, select an option.
    The option specifies when the script will run to process the content. For more information, see Configuring content processing for web applications, in Chapter 7 .
  8. To add the new SED script and processing configuration, click Add New.

Using SED scripts: recommendations and other considerations

Once a particular SED script pattern match has been made, only the associated SED script run. No SED scripts that follow will run.

SED scripts are most easily written with an exclamation point ( ! ) as a separator, since this greatly reduces the need to escape characters in the script.

Start with a single SED script that makes a minor change to content first. Then modify from there. The SED script test button is useful as is a Linux system with SED for testing.

Java applet code issues

A signed Java applet is an applet containing a signature that verifies the source of the applet. If a signed Java applet refers to an Internet site other than the one the applet came from, the FirePass controller cannot make the appropriate host name or path substitutions in the URL, because making substitutions invalidates the applet signature. For more information about Java applet resigning, see Preventing Java byte code rewriting, in Chapter 7 .

In these situations, you cannot use a Portal Access connection to access the web site. Instead, use Application Access (App Tunnels) or Network Access.

JavaScript restrictions

Web pages can have JavaScript programs embedded in them. Sometimes JavaScript programs have requirements that do not work inside a FirePass controller Web Application connection.

For example, if a JavaScript program tests URLs to verify that they begin with http://, this can cause a problem for a Web Application connection because every URL that goes through the connection goes over a secure connection, and a secure connection requires that URLs start with https://.

If you identify a JavaScript problem caused by a requirement such as this, you can use a SED script to modify the JavaScript. Or, you can use Application Access (App Tunnels) or Network Access instead of a Portal Access connection.

For more information about Java script issues, see Scanning for embedded script code, in Chapter 7 .

For detailed instructions on how to identify and respond to specific problems you encounter, see Solution SOL3084 on the AskF5sm technical support site.




Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)