On Wed, 14 Apr 2010 18:10:04 +0100, "Niall O'Cuilinn"
wrote:
> Hi
>
> I had a look at the null-body values. They correctly match the length of
> the HTTP 302 response headers block. The extra two bytes is an extra
line
> return. You can see that after the last header there are three '\r\n'
line
>
Hi
I had a look at the null-body values. They correctly match the length of the
HTTP 302 response headers block. The extra two bytes is an extra line return.
You can see that after the last header there are three '\r\n' line returns. I
tried removing one of them but the result was the same.
I
Hi,
Just resending the correct request and response:
ICAP Request from Squid:
REQMOD icap://10.1.1.25:1344/reqmod ICAP/1.0\r\n
Host: 10.1.1.25:1344\r\n
Date: Mon, 12 Apr 2010 14:25:39 GMT\r\n
Encapsulated: req-hdr=0, null-body=398\r\n
Allow: 204\r\n
\r\n
GET http://c.proxy.com/www.test.com/ HTTP
Hi Christos
Thanks for the reply.
Sorry that was my mistake, I removed some sensitive info from the location
header URL but forgot to modify the null-body value.
It should have read "null-body=100" (I removed 60 chars/bytes). You might be
right and it might still be out by two. I will have a l
Niall O'Cuilinn wrote:
Hi,
I have recently moved from Squid 3.0 to Squid 3.1. I am trying to integrate it
with an ICAP server.
I am having a problem where Squid 3.1 is rejecting some responses from the
ICAP server which Squid 3.0 accepted.
The response in question is a REQMOD response where
Hi,
I have recently moved from Squid 3.0 to Squid 3.1. I am trying to integrate it
with an ICAP server.
I am having a problem where Squid 3.1 is rejecting some responses from the
ICAP server which Squid 3.0 accepted.
The response in question is a REQMOD response where the ICAP server is
retu
