Traditionally Web Service application protocols have defined their own error and status reporting mechanisms. TAS3 standardizes the status reporting by adding a standardized SOAP header that the application SHOULD insert if it wishes to enable some automatic TAS3 processing. This is especially important for automation of Online Compliance Testing.
Some ways the errors can be reported
Network or socket layer, e.g. drop the connection in case of a security violation. This is very extreme response and SHOULD NOT be used normally, unless there is a genuine threat, such as suspected Denial-of-Service (DoS) attack.
HTTP layer error codes. In normal operation, 200 should be used. In particular 4xx and 5xx codes SHOULD NOT be used to indicate authorization errors deep in the application or application errors. The HTTP error codes SHOULD generally be used for errors that are detected at web server level.
Application platform errors, such as stack backtraces, SHOULD NOT happen. All errors SHOULD be trapped and appropriately reported by the application. Despite this rule, the reality of application development means that stack traces will be output by buggy or immature software.
SOAP faults. Generally SOAP faults should only be used to indicate SOAP transport level errors, as defined by SOAP and ID-WSF specifications.
The API, such as tas3_get_fault(), for creating and inspecting TAS3 related SOAP faults is described in section 3.1.13 "SOAP Fault and Status Generation and Inspection".
ID-WSF special headers. Some ID-WSF level errors cause an ID-WSF specific SOAP headers to be emitted in the response.
TAS3 error header SHOULD be used to report all TAS3 and application level errors.
Application level error mechanisms MAY be used to report application level errors. It is RECOMMENDED
that the application level protocols be designed
to use the TAS3 error headers or at least
the Liberty Utility schema dedined