Re: Explaining internal errors

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Wed, 30 Jun 2010 17:39:07 -0600

On 06/30/2010 05:17 PM, Amos Jeffries wrote:

> Okay; just to clarify what we are talking about here:

> %err_code - name of ERR_* page the user was shown (if transaction was
> non-recoverable).

Yes, pretty much. It is the ERR_* page that Squid decided to serve to
the user. Whether the user was shown anything, we do not know. In the
extreme case, the user may have disconnected before we could reply.

> %err_detail - series of N error codes which occurred processing the
> transaction.

Just one [first] "error code", for now. Reporting more than one may be a
good idea for future work, but we are usually mostly interested in what
caused the error and not what happened during error handling.

> By the above, I mean that every protocol involved may produce it's own
> error codes. I was worried that you only had one being logged (such as
> errno).

For now, I am logging what caused ERR_* page generation. xerrno is a
good example. FTP response code is another example. Not all cases are
currently covered or covered well.

The current patch is attached, FYI. It is not ready for merging yet.

Here is an access.log sample from a lab test, with
logformat xsquid %Ss/%03Hs %err_code/%err_detail %<Hs

  NONE/500 ERR_ICAP_FAILURE/100001 -
  NONE_ABORTED/500 ERR_ICAP_FAILURE/100001 -
  TCP_MISS/200 -/- 200
  TCP_MISS/200 ERR_ICAP_FAILURE/100004 200
  TCP_MISS/500 ERR_ICAP_FAILURE/100003 200
  TCP_MISS/500 ERR_ICAP_FAILURE/- 200
  TCP_MISS_ABORTED/000 -/- -
  TCP_MISS_ABORTED/000 -/- 200
  TCP_MISS_ABORTED/500 ERR_ICAP_FAILURE/100003 200

Cheers,

Alex.

Received on Wed Jun 30 2010 - 23:39:56 MDT

This archive was generated by hypermail 2.2.0 : Thu Jul 01 2010 - 12:00:08 MDT