Hi Alex
With your explanation, I was able to reproduce the behaviour:
-> I opened a website within the browser
-> Before the site was loaded completely, I closed the browser
-> This causes squid to close the current icap-transaction (as you
described) (-> ABORT-entries in the access.log)
-> In the icap-log, I have the icap-error mentioned in my first post.
So, this behaviour makes now sense. Probably the icap-daemon
(third-party software) could be advised, not to throw an error but
rather an informational message.
Thanks a lot for your help and hints.
Kind regards,
Tom
On Fri, Jun 21, 2013 at 5:13 PM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 06/21/2013 02:05 AM, Tom Tom wrote:
>> Hi
>>
>> Running squid 3.3.4 as an icap-client:
>>
>> Sometimes, I got on our ICAP-server (runs on the same box as squid)
>> errors like: "ERROR write error: Connection reset by peer"
> ...
>> For me, the following lines seems curious:
>> 2013/06/21 09:46:31.756 kid4| Xaction.cc(488) noteInitiatorAborted:
>> Initiator gone before ICAP transaction ended
>> 2013/06/21 09:46:31.756 kid4| Xaction.cc(503) setOutcome: ICAP_ERR_GONE
>
>> In the access.log, the error behaves like this:
>> [Fri Jun 21 09:46:31 2013].756 0 10.xx.xx.xx NONE_ABORTED/000 0
>> GET http://www9.dict.cc/img/amtop1.gif USER HIER_NONE/- -
>>
>> The behaviour seems not to be reproducable. But it occurs n-times a
>> hour. I also tried with set "icap_persistent_connections off". But
>> this results in the same manner.
>
> Sounds like the HTTP client disconnected from Squid, forcing Squid to
> abort related ICAP (and possibly server-side HTTP) transactions. This is
> normal, but your ICAP server decided to complain about it. Ignore this
> unless something does not appear to work for your HTTP clients.
>
>
> HTH,
>
> Alex.
>
Received on Mon Jun 24 2013 - 08:07:09 MDT
This archive was generated by hypermail 2.2.0 : Mon Jun 24 2013 - 12:00:05 MDT