On Wed, 14 Mar 2007, Henrik Nordstrom wrote:
tis 2007-03-13 klockan 14:50 +0900 skrev Steven:
The third patch (transparent-pipeline.patch) is designed to allow squid
to
handle non-http traffic. If a request can not be decoded by squid, and
it
was a transparently intercepted requets, it
> -Original Message-
> From: Henrik Nordstrom [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 14 March 2007 9:30 AM
> To: Steven Wilton
> Cc: 'Adrian Chadd'; squid-dev@squid-cache.org
> Subject: RE: A few patches
>
> tis 2007-03-13 klockan 15:46 +0900 skrev Steven Wilton:
>
> > Good point.
Is there anyone able to give me a good description of the how-and-why of
MemPool? specifically the MEMPOOL_CLASS() macros and acl_ip_data.
I have a segfault occuring when an acl_ip_data object is created.
Following several others which appear properly, but definately during the
new() somewhere in
tis 2007-03-13 klockan 14:50 +0900 skrev Steven:
> The third patch (transparent-pipeline.patch) is designed to allow squid to
> handle non-http traffic. If a request can not be decoded by squid, and it
> was a transparently intercepted requets, it will be transformed to a
> CONNECT request to
tis 2007-03-13 klockan 15:46 +0900 skrev Steven Wilton:
> Good point. The only problem is that (under Linux at least) we can't find
> out the original destination port (ie if traffic destined for port 80 is
> redirected to port 3128).
conn->me has the original IP and port in transparently interc
> -Original Message-
> From: Adrian Chadd [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 13 March 2007 4:59 PM
> To: Steven Wilton
> Cc: 'Adrian Chadd'; squid-dev@squid-cache.org
> Subject: Re: A few patches
>
> On Tue, Mar 13, 2007, Steven Wilton wrote:
>
> > Good point. The only problem i
I've attached 3 patches to this message for comment.
The first patch (transparent-pipeline.patch) is simple - I'd like to allow NTLM
auth to work even when pipelined requests are enabled, but only for transparent
requests. I think that this is a safe option, as the web browser thinks it's
talk
On Tue, Mar 13, 2007, Steven Wilton wrote:
> Good point. The only problem is that (under Linux at least) we can't find
> out the original destination port (ie if traffic destined for port 80 is
> redirected to port 3128). Would you suggest this as a configuration option
> on a per-port basis? (i
