This patch trying to handle at least the following three cases when we are
reporting error details to the user and logging error details:
1) Shallow error: The same code discovers the error and creates the
error page. The request details will be in sync with the error page
details because they are discovered at the same time, by the same code.
2) Honored deep error: Somewhere deep inside, say, ICAP or DNS code, an
error was detected and detailed. The error condition/answer slowly and
asynchronously propagated to the place where the error page is being
created. We want to preserve that original deep detail if any or provide
the current high-level detail if no deep detail is available.
3) Bypassed deep error1 followed by error2: Somewhere deep inside, say,
ICAP or DNS code, error1 was detected and detailed. The error1 condition
started propagating up but the ICAP or DNS transaction was eventually
successfully retried. Later, a deep or shallow error2 was discovered.
The error1 detail becomes irrelevant when we started to retry the failed
transaction.
This patch:
- Reset the error details when ICAP transactions retried, adaptation services
retried or replaced by the fail-over service and when the forwarding code
retry the connection to the destication servers.
- On SSLBump errors the error details, logged in both master CONNECT request
plus the first tunnelled GET request. To achieve this the error details
of the bump-server-first fake request saved to the CONNECT HttpRequest
object, and the logging of CONNECT request delayed until we have the
bump-server-first answer (freeAllContexts called after SSL-Server answered).
- Fix the cases where we set custom error codes (internal squid error codes)
to ErrorState::xerrno member. This member is only for system errors.
- We should not set ErrorState::xerrno to system err number unless we know
that the current system error triggered the error page generation.
This patch sets this member only to the system errorno passed by squid
API (eg AsyncCalls API).
This is also fix a possible bug in gopher.cc subsystem.
- We are setting the HttpRequest:detailError inside ErrorState::BuildHttpReply
method, where we have all the information required to corrently build
HttpRequest error details.