In our proprietary proxy we used the first approach. There were reserved name spaces for core usage but only a single name for the error. Actually we had two names one with an error number as value and a second one with a human readable error text. A lot of state was made available this way and it was even possible to steer the execution of plugins this way, e.g. each plugin also had their own name space, something like @plugin_xxx. And as the same mechanism was used a general rule based plugin was able to access and modify the values regardless of it was the URL, header, IP address or a custom plugin value. For example the decompression of the content for the plugins was controlled this way.
Roland -----Original Message----- From: James Peach [mailto:jpe...@apache.org] Sent: Friday, April 17, 2015 1:28 AM To: dev@trafficserver.apache.org Subject: Re: Reporting core errors to plugins > On Apr 16, 2015, at 3:39 PM, Alan M. Carroll <a...@network-geographics.com> > wrote: > > 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. I prefer the second approach for 2 reasons. (1) I think that it generalizes usefully. For example, you cold use it to publish transaction history, plugin handling, connection retries, and basically arbitrary internal state. (2) you can reserve these headers for ATS core, preventing plugins from writing them, so the information is more trustworthy. J
