> On Apr 16, 2015, at 5:54 PM, Alan Carroll
> wrote:
>
> A third option is to add an API and data on the HTTP state machine to store
> the error code. This has the issue that it's harder to have multiple
> conditions active. On the other hand it's not overloading some other
> mechanism and w
I would find something where I can make programmatic decisions based on the
general class of error, e.g. "was a client side problem" "was a cache related
problem"
"was an origin connection problem" "was a protocol violation" most useful.
While also being able to get the specific error values.
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
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
To: dev@trafficserver.apache.org
Sent: Thursday, April 16, 2015 3:39 PM
Subject: Reporting cor
