RE: IPv6 support
I was responsible for the first Squid IPv6 patch destined to bit-rot. Having observed the error of my ways if not actually learnt by re-doing, I second Adrian's excellent advice! Also it is important to emphasise Henrik's point that Squid still needs to compile on boxes that do not have the standard IPv6 facilities available, ie. There needs to be at least a couple of ifdef's retained forever, although as few as possible is preferable. Roger. -Original Message- From: Adrian Chadd [mailto:[EMAIL PROTECTED] Sent: Thursday, 3 March 2005 12:58 PM To: squid-dev@squid-cache.org Subject: Re: IPv6 support I know this may not be completely relevant to the ipv6 discussion, but you buy a lot of flexibility if you abstract out the socket API /usefully/. You're then able to do the following: * easily deal with the different crack unices have when twiddling socket stuff (eg, via ioctls, grabbing the source address of connections in client_side.c(c) or http.c(c), etc.) * supporting wildly(!) different APIs, such as windows The only place I see this really breaking is in the ACL code. Adrian -- Adrian Chadd"You don't have a TV? Then what's <[EMAIL PROTECTED]> all your furniture pointing at?"
FW: IPv6 support
I was responsible for the first Squid IPv6 patch destined to bit-rot. Having observed the error of my ways if not actually learnt by re-doing, I second Adrian's excellent advice! Also it is important to emphasise Henrik's point that Squid still needs to compile on boxes that do not have the standard IPv6 facilities available, ie. There needs to be at least a couple of ifdef's retained forever, although as few as possible is preferable. Roger. -Original Message- From: Adrian Chadd [mailto:[EMAIL PROTECTED] Sent: Thursday, 3 March 2005 12:58 PM To: squid-dev@squid-cache.org Subject: Re: IPv6 support I know this may not be completely relevant to the ipv6 discussion, but you buy a lot of flexibility if you abstract out the socket API /usefully/. You're then able to do the following: * easily deal with the different crack unices have when twiddling socket stuff (eg, via ioctls, grabbing the source address of connections in client_side.c(c) or http.c(c), etc.) * supporting wildly(!) different APIs, such as windows The only place I see this really breaking is in the ACL code. Adrian -- Adrian Chadd"You don't have a TV? Then what's <[EMAIL PROTECTED]> all your furniture pointing at?"
squid ICAP developer
Hello all, I am Tsantilas Christos (chtsanti at users dot sourceforge dot net), I am working with ICAP protocol and I am interested to help the development of ICAP client for squid. Thanks, Christos
Re: ICAP patches for squid-2.5.STABLE8
On Thu, 3 Mar 2005, Christos Tsantilas wrote: I would like to help more on develpment squid-2.5 ICAP branch. Great! I am goint to try but please do not abuse me about the result. My only problem is that I don't know if I will have enough time for maintaining the icap branch. It doesn't require very much time, most of the routine job is automated using scripts. The main criteria is being able to take the time required to run these scripts and fix up conflicts when required to keep the patch up to date. I am spending most of my spare time for c-icap developement. But, on the other hand, c-icap without a good icap enabled proxy, has not any reason to exists... If you use Squid-ICAP in your testbed then maintenance becomes quite natural. As long as one is keeping the maintenance reasonably active it is not much of a burden. Problem only arises when a long time passes allowing the amount of changes between the branch and the current version to accumulate, making conflicts harder to resolve. The Squid development process is a fairly open process as you can see on http://devel.squid-cache.org/. But for a development or branch of Squid to keep active requires one or two developers actively caring for it. As already expressed in this thread the ICAP branch is currently a bit on the low edge of amount of developers working on it. I am spending most of my spare time for c-icap developement. Same for me, but Squid ;-) But, on the other hand, c-icap without a good icap enabled proxy, has not any reason to exists... And ICAP enabled Squid is very powerful, and available for all to deploy their ICAP solutions. May I ask, do you know someone (individual or company) which work on icap client for squid-3? I plan to start working on ICAP for Squid-3 before the summer. Unfortunately Squid-2.5 maintenance (including my Squid-2.5 branches; ssl, custom_log, icap_streaming, rproxy, collapsed_forwarding, external_acl_fuzzy and a few more) is still taking up too much of my available time to allow me to focus fully on Squid-3 just yet, but the number of unresolved bugs in Squid-2.5 is steadily declining even if some new bugs is introduced every now and then so things are looking very optimistic. Regards Henrik
Re: squid ICAP developer
On Thu, 3 Mar 2005, Tsantilas Christos wrote: I am Tsantilas Christos (chtsanti at users dot sourceforge dot net), I am working with ICAP protocol and I am interested to help the development of ICAP client for squid. You have now been given access to the devel.squid-cache.org services. While you wait for the permissions to get updated (can take up to 12 hours) please read the documents on how to use the services and rules http://devel.squid-cache.org/CVS.html (tools, routines, howto tips etc) http://devel.squid-cache.org/rules.html (usage guidelines) And please subscribe to the squid-dev mailinglist by sending a message to [EMAIL PROTECTED] Regards Henrik
Re: Odd HTTP response codes
On Fri, 2005-02-25 at 20:10 +1100, Andrew Bartlett wrote: > On Tue, 2005-02-15 at 00:13 +0100, Henrik Nordstrom wrote: > > On Tue, 15 Feb 2005, Andrew Bartlett wrote: > > > > > I'm not sure (and I won't be onsite today). The other details are: > > > > > > Client: Mozilla Firefox (post 1.0 snapshot) > > > Authenticated with NTLM > > > > > > This is over the past 2 weeks worth of logs, so I'm not sure if it > > > happens 'often' (and I've yet trawled the logs for a 'normal' case on > > > this URL). > > > > Just to be sure you may want to upgrade to 2.5.STBLE8 (and maybe the > > released critical bugfix at the same time). There was a HTTP protocol > > corruption bugfix between 2.5.STABLE8-RC4 and 2.5.STABLE8, and a critical > > old bug discovered just after the release. > > > > >From an inital analysis it does not look like the HTTP protocol corruption > > bug could possibly trigger on this object however, and cerainly not in a > > manner triggering the given symptoms.. but you never know. > > After updating to STABLE8 and the post-patches, I got another in my mail > today, and it's always the same site: > > 1109296746.064 9824 .client.internal.hawkerc.net > TCP_MISS/179897680 1618 GET > http://pimg.163.com/search_js/so_sports_icon.gif xxx > DIRECT/61.177.95.40 text/html Just an interesting note - I've just seen this on all 3 client platforms. WinXP (MSIE), Win2k (firefox) and Linux (Mozilla 1.7). The mozilla client isn't doing NTLM (ident or basic auth). Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net signature.asc Description: This is a digitally signed message part
