Views

Troubleshooting: Deciphering Http Traffic Detail

If configured to store http traffic and make it available, the simulator's SSO Traffic tab provides a link for each entry. Upon selecting the link content similar to the following will open in an editor or new tab depending on your browser and operating system configuration. The content below is for accessing the /public/debug.jsp page as part of the dual debug page example. The line numbers are not included in the content but are used for discussion in this page. Important items in this content are discussed separately below in the hope that such content will be of use in troubleshooting problems when they arise.

Lines 1 to 4 are solely for serving up the page to the browser telling the browser to treat it like simple text and has nothing to do with the actual traffic passing through the proxy.

Line 5 indicates the total elapsed time from when the request was received by the proxy to when the socket to the client (the browser) was closed after sending a response.

Line 6 indicates the total number of bytes that did get sent to the back end server or would have been sent in the case of a response generated directly by the proxy. This number is the number of bytes from line 9 a the start of the http method, GET in this case, to and including the carriage return line-feed characters on line 24 indicating the end of the headers. This particular request has no body. If it did then that content would also be included in the count.

Lines 8 and 9 serve to convey what the simulator did to the http request line. As you can see the request line arrived at the simulator with a path of /public/debug.jsp and was rewritten to /admin/debug.jsp. This is a direct result of the cctx attribute on line 13 of the dual debug example config file differing from line 17 of that file. The cctx value indicates the path prefix in the canonical space that if seen causes that request to be proxied to the target host thost and port tport on lines 14 and 15 of that directive with the part of the path matching the cctx prefix being replace by the prefix of the tpath. This allows the canonical space to differ from the application space. Hence the reason that these two lines are have the simulator-specific descriptive text preceding the actual request lines that start with the http method GET. WARNING: before using request URL rewriting be certain that your application environment in WAM will support it.

Lines 10 is the http Host header. This header is used to match a request up with a by-site directive such as that on line 12 of the dual debug example config file. By matching on that by-site element the request then became subject to the directives nested within that element such as the cctx-mapping element discussed above. However, based upon other attributes of that directive the host header shown in this text may not be the one used to match the by-site element since it too may be rewritten. See the <cctx-mapping> element for details. If the host is rewritten then an additional header, X-Forwarded-Host will be injected with the original value of the host header received by the proxy and used for matching the request with a by-site element.

Lines 11 through up to the empty line 24 are additional headers passed from the browser or injected by the simulator. Any header starting with policy- was injected by the simulator. For more details on these specific headers see SSO Injected Headers. However, there are a few more headers that are specific to the simulator which we be discussed separately.

Line 17 is the Connection header with a value of close. This is injected by the simulator telling the server to ignore any Keep-Alive header such as that included by the browser in line 16 and close this connection once it has sent a response. This prevents a single socket connection from having more than one request thus making tracking and association of requests and responses in the simulator be bounded simply by a client socket and related server socket life cycle. You'll note the same header is injected into the server's response on line 33 by the simulator if not include by the server already.

Line 18 is a custom header, X-shim: handled, that helps to prevent infinite loops where the simulator is configured erroneously to proxy back to the proxy port itself. If an incoming request contains this header then we know that it came from the simulator and an error response is returned thus breaking the infinite loop.

Line 21 is a custom header, X-connId, that indicates the connection identifier as it passed through the simulator. This will be a zero-prefixed number from zero up to the max-entries value specific via the <console-recording> element if included or 1000 if not. Upon reaching the max number it starts over again at zero. This is injected into both the request passing on to the server and the response sent back to the client as can be seen in line 34. This allows for correlating between requests hitting the server and returning to the browser with entries showing in the console's SSO Traffic tab.

Line 25 is of particular help when troubleshooting problems. It shows the host and port to which the simulator connected to proxy the request onward. This will match the settings of the <cctx-mapping> element that matched the request and was used to route the request to a back end application. For SSO Traffic that resulted in a response directly from the proxy this line will contain the text, Proxy Generated Response.

Lines 27 through 35 contain the response headers received from the application and any injected by the proxy as noted above.

And finally, Lines 37 onward contain the payload of the http response clipped out here for brevity.