Alex Rousskov wrote:
On Fri, 2008-04-18 at 15:40 +1200, Amos Jeffries wrote:
IMO, This should be queued as part of the 3.1 cleanups, but not as
urgently as some other issues.
The priorities as I see them now are:
- immediately fixable and urgent bugs.
- completing the dedicated 3.1
On Wed, Apr 16, 2008, Alex Rousskov wrote:
In short, we have several related problems here: (a) client_side code is
incapable of reliably identifying whether comm_close has been called;
(b) ConnStateData::isOpen may not work anymore; (c) client_side code
uses many different ways to identify
On Fri, 2008-04-18 at 18:34 +1200, Amos Jeffries wrote:
Alex Rousskov wrote:
On Fri, 2008-04-18 at 15:40 +1200, Amos Jeffries wrote:
IMO, This should be queued as part of the 3.1 cleanups, but not as
urgently as some other issues.
The priorities as I see them now are:
-
On Fri, 2008-04-18 at 16:15 +0800, Adrian Chadd wrote:
On Wed, Apr 16, 2008, Alex Rousskov wrote:
In short, we have several related problems here: (a) client_side code is
incapable of reliably identifying whether comm_close has been called;
(b) ConnStateData::isOpen may not work anymore;
Hello all,
Using ICAP servers with Squid, I saw that Squid does not provide
X-Client-IP header in respmod (header is present in reqmod).
Not really a bug, but it makes it harder to follow HTTP
request/response exchanges with an ICAP server.
Is it linked to Squid or ICAP stack implementation, and
On Fri, Apr 18, 2008, Alex Rousskov wrote:
I'd suggest another option - roll back all of the async calls changes to the
comm code, stabilise the codebase without it and re-evaluate what should
occur (in smaller chunks, rather than dropping in a new comm manager)
before reintroducing it.
