I think logging such information is very important and useful, so, I am +1 with
an(y) approach that allows logging easily without breaking too much sweat.
Thanks,
Sudheer
From: Alan M. Carroll <[email protected]>
To: [email protected]
Sent: Thursday, April 16, 2015 3:39 PM
Subject: Reporting core errors to plugins
Based on some discussions here at the summit, we would like to add the ability
for the core to report certain error conditions to plugins. We have at least
one use case where it is critical to be able to distinguish different causes
for a 502 error (origin server down, cache write lock missed, etc.).
The basic concept is the core adds a header to the transaction which reports
the error. This lets plugins do special handling without embedding that (or
related configuration values) in the core and potentially to log those
conditions.
There are two approaches.
The first is to have a single header, @ats-internal, which is used for
reporting. This would be a comma list in the standard HTTP header way with each
condition code required to be unique. For instance, a cache write lock miss
would be "CACHE_WL_MISS" yielding '@ats-internal: CACHE_WL_MISS". This is
easier to log but a bit harder to process for different errors (since you have
to search the values).
The second is to designate another character as "do not print this header",
such as '%', and reserve that for the ATS core. In this case we can use the
header namespace without concern for name collisions. The previous case would
then be "%cache-doc-error: WRITE_LOCK_FAILED". This is harder to log but easier
to detect a specific condition you want to handle.
Any comments are welcome.
