Search squid archive

Re: ICAP problem in 3.1.18

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/01/2012 4:01 a.m., Daniel Beschorner wrote:
One month ago I reported an ICAP regression in 3.1.17/18.

In meantime I tracked down the problem to patch 10403 (Bug 2619).
Maybe it helps to find the issue.

Thank you
Daniel

--------
After upgrading to 3.1.18 (+adaption compile patch) the following url =
never stops loading in the browser

http://x.ligatus.com/cgi-bin/ivw/CP/11260-365/83-1056/129647-107545-_129709=
-105679-_128565-101085-//

If I bypass the ICAP server for this url (which is indeed a redirect to =
http://x.ligatus.com/blank.gif) all works fine.

No. That is a redirect to the URL "/blank.gif" and URL with no domain and no protocol scheme. In HTTP that is an invalid Location: header, which requires an absolute URL. This could be screwing up an ICAP server which expects valid HTTP.

Your UA is assuming that it is a redirect to the same domain as the original request. It could as easily be a redirect to http://www.ivwbox.de/blank.gif which is the security domain the P3P header says the reponse is part of. This is a XSS vulnerability.

Besides the invalid Location: header the 302 is cacheable and requires revalidation. However performing that revalidation produces an invalid status code of some type according to redbot.org. I was not able to replicate the invalid status to see what it it is complaining about. But if that revalidation failure happens through Squid the ICAP coudl be breaking on that.

There is also a strange 1-byte body attached. It could be the body pipeline or network I/O functions hung waiting for more data in order to prevent single-byte packets.

Amos


[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux