Applies To:

Show Versions Show Versions

Manual Chapter: Using Web Applications Engine Trace
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

13 
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.
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 way.
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.
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.
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 controllers 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 users name whose session you want to trace.
5.
To get a list of active sessions for the user, click Get user sessions.
The users 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.
8.
After the user experiences the problem and the screen finishes loading, click Download and save the trace file to your local hard drive.
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 users browser to finish loading the content or time out.
You can alternatively click Get user sessions again and browse the trace log files within the current Administrative console window using the Browse link.
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.
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.
Images referenced in the associated backend_<nnnn>.html file, received by the FirePass controller from the applications web server.
Messages representing the request and response exchange between the FirePass controller and the client requesting the page.
This is the data from the applications web server accessed by the user session, after the FirePass controller has processed it and added state-change information.
Images referenced in the associated frontend_<nnnn>.html file, sent to the client by the FirePass controller.
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.
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_nnnnnnnn
where nnnnnnnn represents the number of client requests recorded in the web trace.
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
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.
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 1, 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.
HTML syntax errors
For more information, see Fixing HTML syntax errors, following.
HTML syntax errors are common. Frequently they are invisible or cause only minor problems with a web pages appearance, but web pages with syntax errors can also result in significant problems in certain browsers or when accessed through a Portal Access favorite.
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.
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.
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.
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 URLs 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 box 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.
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, and Adding a SED script.
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.
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 boxes 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 box 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.
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.
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 these situations, you cannot use a Portal Access connection to access the web site. Instead, use Application Access (App Tunnels) or Network Access.
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 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)