On 6/12/2016 9:03 p.m., Silamael wrote:
> On 05.12.2016 13:58, Amos Jeffries wrote:
>> On 5/12/2016 11:17 p.m., Silamael wrote:
>>> This sounds somehow wrong to me, the ICAP service doesn't have a
>>> problem, just the HTTP request being forwarded is borken. Therefor is no
>>
>> The ICAP service appears to be producing URLs without any host segment
>> at all ("") instead of using the input "." or some other value of its
>> choosing.
>>
>> Strictly speaking Squid should accept that as a URL with no hostname,
>> just like it accepted the odd '.' hostname. That is one of the issues
>> bug 1961 seeks to fix.
>
> Hi Amos,
>
> So, you think the URL Squid complains about is returned by our ICAP service?
> As far as I understood the log messages, the URL was not sent to the
> ICAP service at all.
> Or am I wrong here?
The exception was thrown from the HTTP request parser when handling the
ICAP service response - which was delivering a new HTTP request message
to use instead of the client-provided request message.
Assuming your statement was correct about the input having '.' hostname.
That means the ICAP changed the URL to 'scheme:///path'.
>
>>> need to suspend the ICAP service at a whole for 30 seconds.
>>> Am I wrong or is this behavior intended?
>>>
>>
>> AIUI, for installations using bypass=yes the behaviour is expected. That
>> setting is not tied to particular types of error, it simply means the
>> service is optional. *any* HTTP request (even good ones) can bypass.
>
> Yeah, that's clear. My problem is, that the service is suspended.
> If there are real problems within the communication with the ICAP
> service, it should be bypassed.
Nod. I think Eliezers solution with the ACL is the best thing to do
while waiting on the Squid fix to handle that URL type. Maybe even keep
it after that if the ICAP service is not liking the input request either.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
