Re: Unparseable HTTP header field & DNS weirdness

Do you have an upstream proxy configured? Cheers, On 21/01/2011, at 3:29 AM, Alex Ray wrote: > This might be nothing, but I notice the following errors in my build > of squid 3.HEAD: > kid1| ctx: enter level 0: > 'http://trailers.apple.com/trailers/global/styles/ipad_black.css > kid1| WARNING:

Re: /bzr/squid3/trunk/ r11178: Added specific flags for Intel(R)'s icc compiler

On Wed, Jan 26, 2011 at 1:50 AM, Amos Jeffries wrote: > On Wed, 26 Jan 2011 00:37:56 +0100, Kinkie wrote: >> *sigh*. An unrelated fix slipped in. >> Do you want me to recommit or is it trivial enough that it can be left >> like this? >> > > The smblib removals? its a bit far back now, but as you a

Re: Sharing DNS cache among Squid workers

On Tue, 25 Jan 2011 17:58:36 -0700, Alex Rousskov wrote: > On 01/13/2011 03:54 PM, Amos Jeffries wrote: >> On 14/01/11 11:20, Robert Collins wrote: >>> On Fri, Jan 14, 2011 at 11:13 AM, Alex Rousskov >>> wrote: On 01/13/2011 02:18 PM, Robert Collins wrote: > Have you considered just hav

Re: Sharing DNS cache among Squid workers

On 01/13/2011 03:20 PM, Robert Collins wrote: > On Fri, Jan 14, 2011 at 11:13 AM, Alex Rousskov > wrote: >> On 01/13/2011 02:18 PM, Robert Collins wrote: >>> Have you considered just having a caching-only local DNS server >>> colocated on the same machine? >> >> I am sure that would be an appropri

Re: Sharing DNS cache among Squid workers

On 01/13/2011 03:54 PM, Amos Jeffries wrote: > On 14/01/11 11:20, Robert Collins wrote: >> On Fri, Jan 14, 2011 at 11:13 AM, Alex Rousskov >> wrote: >>> On 01/13/2011 02:18 PM, Robert Collins wrote: Have you considered just having a caching-only local DNS server colocated on the same ma

Re: [PATCH] bug 3081: comm layer cleanups for TCP acceptor

On Tue, 25 Jan 2011 17:42:03 -0700, Alex Rousskov wrote: > On 01/22/2011 06:46 AM, Amos Jeffries wrote: > >> However we cannot drop the CommCbFunPtrCallT and AsyncCallT copy >> constructors. Notice how they explicitly call AsyncCall(a,b,c) instead >> of the AsyncCall copy contructor. Without this

Re: /bzr/squid3/trunk/ r11178: Added specific flags for Intel(R)'s icc compiler

On Wed, 26 Jan 2011 00:37:56 +0100, Kinkie wrote: > *sigh*. An unrelated fix slipped in. > Do you want me to recommit or is it trivial enough that it can be left > like this? > The smblib removals? its a bit far back now, but as you are the only comitter since it could be done. I can split it on

Re: [PATCH] bug 3081: comm layer cleanups for TCP acceptor

On 01/22/2011 06:46 AM, Amos Jeffries wrote: > However we cannot drop the CommCbFunPtrCallT and AsyncCallT copy > constructors. Notice how they explicitly call AsyncCall(a,b,c) instead > of the AsyncCall copy contructor. Without this we loose the call > debugs() and the ID creation. > > Adding the

Re: /bzr/squid3/trunk/ r11178: Added specific flags for Intel(R)'s icc compiler

*sigh*. An unrelated fix slipped in. Do you want me to recommit or is it trivial enough that it can be left like this? K. On Tue, Jan 25, 2011 at 10:29 PM, Francesco Chemolli wrote: > > revno: 11178 [merge] > committer: Francesco Che

Re: /bzr/squid3/trunk/ r11181: Portability fix: icc doesn't like string literal in assert checks

>> Ok done. >> What is the process for queueing it up for backporting? > > Just a heads-up to me (like this). > Otherwise I tend to go by the reported earliest sighting version in the > bug report or if it looks important and is easy to port back. Could it be a nice candidate for a custom multi-va

Re: /bzr/squid3/trunk/ r11181: Portability fix: icc doesn't like string literal in assert checks

On Tue, 25 Jan 2011 23:50:40 +0100, Kinkie wrote: > On Tue, Jan 25, 2011 at 11:39 PM, Kinkie wrote: >> On Tue, Jan 25, 2011 at 11:26 PM, Amos Jeffries wrote: >>> On Tue, 25 Jan 2011 23:19:46 +0100, Francesco Chemolli wrote: revn

Re: /bzr/squid3/trunk/ r11181: Portability fix: icc doesn't like string literal in assert checks

On Tue, Jan 25, 2011 at 11:39 PM, Kinkie wrote: > On Tue, Jan 25, 2011 at 11:26 PM, Amos Jeffries wrote: >> On Tue, 25 Jan 2011 23:19:46 +0100, Francesco Chemolli wrote: >>> >>> revno: 11181 >>> committer: Francesco Chemolli >>> branch

Re: /bzr/squid3/trunk/ r11181: Portability fix: icc doesn't like string literal in assert checks

On Tue, Jan 25, 2011 at 11:26 PM, Amos Jeffries wrote: > On Tue, 25 Jan 2011 23:19:46 +0100, Francesco Chemolli wrote: >> >> revno: 11181 >> committer: Francesco Chemolli >> branch nick: trunk >> timestamp: Tue 2011-01-25 23:19:46 +0100

Re: /bzr/squid3/trunk/ r11181: Portability fix: icc doesn't like string literal in assert checks

On Tue, 25 Jan 2011 23:19:46 +0100, Francesco Chemolli wrote: > > revno: 11181 > committer: Francesco Chemolli > branch nick: trunk > timestamp: Tue 2011-01-25 23:19:46 +0100 > message: > Portability fix: icc doesn't like string litera

Re: NTLM passthrough broken in 3.1.3 and higher

On Tue, 25 Jan 2011 13:26:02 -0800, Phil Oester wrote: > In revision 9957 (Remove HTTP/1.1 sent to clients), NTLM passthrough > was broken for Outlook clients, which require 1.1 to work properly. > When receiving 1.0, Outlook closes the connection (which breaks NTLM > since it requires a continued

NTLM passthrough broken in 3.1.3 and higher

In revision 9957 (Remove HTTP/1.1 sent to clients), NTLM passthrough was broken for Outlook clients, which require 1.1 to work properly. When receiving 1.0, Outlook closes the connection (which breaks NTLM since it requires a continued session). Version 3.1.2 works fine for these clients. Note th

[PATCH] external ACL non-caching update - round 2

Admin configure ttl=0 and/or negative_ttl=0 to prevent Squid storing the ACL lookup results. The problem is that results still get cached and re-used for the grace= period or one second, whichever is larger. Also, in the event where two or more requests with identical details needing to be looke

Re: [PATCH] NTLM authentication broken for Mozilla/3.0 User-Agents

On 25/01/11 20:56, Fabian Hugelshofer wrote: Hi, On 12/01/11 00:14, Henrik Nordström wrote: tis 2011-01-11 klockan 11:37 +0100 skrev Fabian Hugelshofer: What do you think about removing the special handling for Mozilla/3 and Netscape/3 agents from HttpMsg.cc? +1 from me. How large is the

Hudson build is back to normal : 3.HEAD-amd64-CentOS-5.3 #1101

See