Intercepting HTTP Errorsby Group Public on Friday March 12 2010 @ 15:15:09 (1/1 Points) |
|
| Tutorial ↪User Guide ✑ Reply ✓ Stick It ✗ Ditch It ⚐ Tag It |
During the normal flow of a script and HTTP error will cause a failure and immediately end the current unit. There are some times however where you would like to look at the failed response. For example, in a live monitor you don't normally care about the content of 404 error page, but sometimes there may be information in there useful for your deployment team. Using HTTP interception you are able to provide a global handler for all errors.
If you are just interested in manually looking at the response for debugging then use Debug.Web→ instead. The interception described here is for when the test itself must inspect the responses.
System.HTTPIntercept
The context entry System.HTTPIntercept is where an intercept handler can be defined. Each handler is defined with the name Single.### where ### is the specific error code to be handled. The value of this entry should be the name of a unit→ to be executed.
Rather than exact numbers a class can be specified, such as Single.4xx. A global intercept can also be defined as Single.xxx, though this may introduce some performance issues.
Single indicates only one such callback will be executed. The most specific one will be chosen. There is currently not other option other than Single.
The below is an example of registering several handlers.
System.HTTPIntercept:Single.504=global.Handle504 System.HTTPIntercept:Single.404=global.Handle404 System.HTTPIntercept:Single.4xx=global.Handle4xx
Note again that if an error code of 404 is returned only one handler will be called: global.Handle404. The generic 400 class fallback will be used for all other 400 level errors.
Supported Modes
The HTTP interception mechanism works in HTMLUnit and ULRMode backends. It does not work in Selenium (it is not possible).
Writing a Handler
When called the actual response is setup as the current response→. It matches the response format→ as RawGetURL.
Be aware that the handler is called outside of the normal execution path. As such checkpoints will be performed, and output, but will not have an influence on the overall test. Where values are emitted, and at what time the callback is executed, is also undefined, thus it should not attempt to communicate with the main test in any fashion. It should simply write notices or files for use outside the system.
TestPlan Intercepting HTTP Errors
