Re: Hello from Mozilla
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Collins wrote: P.S. So every time that I set up squid on my machine to test something, it always denies access to me out of the box. I finally figured out it's because you don't allow localhost connections by default. Should you be adding a line like acl localnet src localhost to squid.conf? Is there a reason why you're allowing 10.0.0.1, etc. to connect, but not localhost? I'd be open to us changing this. It is a [small] risk for a bastion host to allow connections from itself because a different account being compromised then allows access via the proxy. I have no evidence to make an assertion about the frequency of deployments on a bastion host vs behind one, and so the only argument I have for preserving it is 'secure as possible by default', which while a good argument isn't the end of the discussion. Your argument is subject to reductio ad absurdam: if you want secure as possible by default, then the default config shold not allow proxied access from *any host at all*. Any host other than localhost should be *less* trusted than localhost. I would argue that enabling only localhost for the default forward proxy configuration is a sane default: people configuring things like bastions ought not to expect to use out-of-the box configs without review / tweakage, while people using Squid as a personal cache ought not to have to do such tweaks. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKVARQ+gerLs4ltQ4RAhlJAKDWsjrr/7IT45r4IPXsXt5Xyfa0zwCffrfr hLbI2vMOIWeHA09Mf+Kdg2k= =bVwt -END PGP SIGNATURE-
Re: bzr 1.11 on squid-cache.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henrik Nordstrom wrote: tis 2009-01-20 klockan 18:48 +0100 skrev Guido Serassio: At 13.12 20/01/2009, Henrik Nordstrom wrote: bzr has been upgraded to 1.11 on squid-cache.org. This release reporedly includes support for case-insensitive filesystems (i.e. Windows). Any news on the line ending side ? There seems to be some progress: http://bazaar-vcs.org/LineEndings/Roadmap What I do not get is if this will require a repository format bump, or just a upgraded working tree format. My reading says that it will require only changes to the working tree, and that it might be usable in limited mode (e.g., only the global config would be supported, rather than per-tree or per-branch options) in 1.12. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJd2jH+gerLs4ltQ4RAjTjAKC5gL/C5F2reKk/i2tgVhmkLL+LeQCfazX+ vjFPpY4NU9HZJ+tDCcP5x2E= =B3cH -END PGP SIGNATURE-
Re: The cache deny QUERY change... partial rollback?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henrik Nordstrom wrote: After analyzing a large cache with significantly declining hit ratio over the last months I have came to the conclusion that the removal of cache deny QUERY can have a very negative impact on hit ratio, this due to a number of flash video sites (youtube, google, various porno sites etc) who include per-view unique query parameters in the URL and responding with a cachable response. Because of this I suggest that we add back the cache deny rule in the recommended config, but leave the refresh_pattern change as-is. People running reverse proxies or combating these cache busting sites using store rewrites know how to change the cache rules, while many users running general proxy servers are quite negatively impacted by these sites if caching of query urls is allowed. Having a single recommended config seems dubious: I for one never run squid as a forward proxy, for instance. We should probably split apart the default / recommended forward and reverse configurations (which are just starting points, right?) and document how to tell which one to start with. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJNAo0+gerLs4ltQ4RAnlrAJ45FgRi1WjkyikSunADePZSOwwBTgCghz+E 9fOaumxljVn99Tm257N1rUw= =Q9De -END PGP SIGNATURE-
Re: Refresh patterns and ACLs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: Mark Nottingham wrote: I'm not convinced it's a great solution, but something like URISpace may be appropriate; http://www.w3.org/TR/urispace.html What's nice about this is that you buy some efficiency by walking down the tree, rather than evaluating a linear set of rules... Interesting spec: I can see uses for it elsewhere. A quick question, (since grubbing around shows you to be the author;): in section 3.3, Path Segments, the semantics of path match=foo are to match the next element in the current path, right? Rather than matching any random element (CSS style), or (for instance) the last element (which would be useful in particular for the empty pattern and filename globs). Is the spec frozen / dead, or could we suggest additions? E.g.: path any=archives and: path last= I can certainly put such extensions into another namespace, but they seem reasonably tightly connected to the existing first match semantics. BTW, I have banged out a Python implementation of a good bit of the spec, including extensions for last element and any element path selectors. I plan to use the library in conjunction with various WSGI middleware to allow for URI-based selection of things like theme, role grants, and caching headers: http://pypi.python.org/pypi/repoze.urispace (I'll work on getting the ReStructuredText on that page to render later). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIuZh2+gerLs4ltQ4RAgzmAJ40134AsAKppeA2sI1V9Ms4r67rMACgiGG+ yBJxxO12RBUI5YXmdCORo4E= =hTI9 -END PGP SIGNATURE-
Re: Refresh patterns and ACLs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: Tres Seaver wrote: Mark Nottingham wrote: I'm not convinced it's a great solution, but something like URISpace may be appropriate; http://www.w3.org/TR/urispace.html What's nice about this is that you buy some efficiency by walking down the tree, rather than evaluating a linear set of rules... Interesting spec: I can see uses for it elsewhere. A quick question, (since grubbing around shows you to be the author;): in section 3.3, Path Segments, the semantics of path match=foo are to match the next element in the current path, right? Rather than matching any random element (CSS style), or (for instance) the last element (which would be useful in particular for the empty pattern and filename globs). Is the spec frozen / dead, or could we suggest additions? E.g.: path any=archives and: path last= I can certainly put such extensions into another namespace, but they seem reasonably tightly connected to the existing first match semantics. BTW, I have banged out a Python implementation of a good bit of the spec, including extensions for last element and any element path selectors. I plan to use the library in conjunction with various WSGI middleware to allow for URI-based selection of things like theme, role grants, and caching headers: http://pypi.python.org/pypi/repoze.urispace (I'll work on getting the ReStructuredText on that page to render later). The PyPI page is still unrendered, but cooked versions of the docs are online here: http://static.repoze.org/urispacedocs/ Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIuZ0O+gerLs4ltQ4RAhZPAJ9q/PKve7pgOkMNkeojd9RRhLJ+zwCgvL1F iowu4qiHOq8fhgsuomi+fiQ= =eSDv -END PGP SIGNATURE-
Re: Refresh patterns and ACLs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Nottingham wrote: I'm not convinced it's a great solution, but something like URISpace may be appropriate; http://www.w3.org/TR/urispace.html What's nice about this is that you buy some efficiency by walking down the tree, rather than evaluating a linear set of rules... Interesting spec: I can see uses for it elsewhere. A quick question, (since grubbing around shows you to be the author;): in section 3.3, Path Segments, the semantics of path match=foo are to match the next element in the current path, right? Rather than matching any random element (CSS style), or (for instance) the last element (which would be useful in particular for the empty pattern and filename globs). Is the spec frozen / dead, or could we suggest additions? E.g.: path any=archives and: path last= I can certainly put such extensions into another namespace, but they seem reasonably tightly connected to the existing first match semantics. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIt3qO+gerLs4ltQ4RAiQoAJ9VCfO8pSohOB8ayLli3LAeymMHswCgiqV7 zrG+JVzw78PRioZqTCyL8T4= =pQdp -END PGP SIGNATURE-
Re: Environment to build a squid helper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henrik Nordstrom wrote: On tis, 2008-08-12 at 22:10 +0200, Guido Serassio wrote: Yes, the resulting feel is not so good I am attemting an MSYS install with the goal of being able to build squid-3 (and 2) just to see how it fares.. Initial results isn't too bad, but the GCC version I installed (4.3.1) barfs a bit about various crap in the Squid code.. Most annoying is that the semantics of extern inline seems to have changed making it fail to link due to new(int) being multiply defined.. not 100% sure how to best fix this.. the choices are either drop the extern part from extern inline or add a gcc function attribute making gcc 4.3+ compile extern inline the gnu-way instead of the current C99 standard-way.. Isn't 'extern inline' a contradiction? There should be *no* linkage of any function being inlined. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIokx++gerLs4ltQ4RAn0XAJ9jlN3tqVxm5lxVfQQ2s3fdlNUtdgCcDMbM W37I+HfIRfhdHJCKr6zUFBs= =0X+X -END PGP SIGNATURE-
Re: Environment to build a squid helper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henrik Nordstrom wrote: On tis, 2008-08-12 at 22:52 -0400, Tres Seaver wrote: Isn't 'extern inline' a contradiction? There should be *no* linkage of any function being inlined. It depends on your viewpoint. inline is only a hint that the function is a candidate for being inlined. It may still be compiled as a separate function. But such a function should be *static*, not *extern*: if it is a reasonable candidate for inlining, then the cost of linking likely dominates the space saved by declariing it 'intern'. In GCC extern inline then meant that the function should have extern linkage if not inlined, or to be exact a call to an external function if outside of this compile unit if not inlined. Quite useful to avoid repeated duplication of the same function in each comple unit Inlining involves repeated duplication of the same function (body) at each call site, no? If inlining is a good idea (trading space at the call site to avoid the overhead of a call setup), then declaring the function extern seems silly. , but unfortunately not part of the standard language definition and gcc 4.3 now changed to follow the standard.. (extern ignored). The change in GCC semantics has been documented in the GCC documentation for quite some time (some years), but as always documentation is never read until there is a problem so it was not discovered there was a change until trying to compile Squid with gcc-4.3. OK. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIolzy+gerLs4ltQ4RApl7AKDNV75b5OrsxUxtVr0ysrgkz5Q67gCgziLm 1lj/fKbY49iG+gDH96iXobM= =82nu -END PGP SIGNATURE-
Re: [MERGE] Closing branch cachemgr-refactoring
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kinkie wrote: Hi all, I'm now satisfied with the work done in the cachemgr-refactoring branch and I propose merging it into squid-3 trunk. Overall view of the changes: - cachemanager is now a singleton - list of actions is now a Vector (still not ideal, but at least it preserves layering) - added object-based action management interface to cachemgr. old-style c interface is still available (via method overload) - cachemgr initialization functions have been moved to each modules' Init call or (where applicable) constructor. This has the effect of reducing each module's interface, and to get rid of some module frameworks' extra initialization work - fixed tests to work with the new framewor (including the creation of a small stub in tests/) - added some documentation While the work is not 100% complete, it's in a state where I'm quite comfortable merging it in. The branch is available at lp:~kinkie/squid/cachemgr-refactor/ (see https://code.launchpad.net/~kinkie/squid/cachemgr-refactor) What I left off is: - change the actionslist from a Vector to a sorted linked-list (need the generic linked-list class first) Is the STL list template unsuitable? - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIe3JP+gerLs4ltQ4RArPfAKDWbsV9TERiAskChZrniAk77/UO6wCeJCpm 5v2TUriD4OmQqAwnqy45AQ0= =o/K7 -END PGP SIGNATURE-
Re: bzr stable branch maintenance and backporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Collins wrote: On Thu, 2008-03-27 at 23:23 +0100, Henrik Nordstrom wrote: Robert, do you have any advice on how to best keep track of what to backport to earlier (i.e. STABLE) releases? ... For a sensible workflow what one really wants is something like this - A changeset starts out as uncategorized - Multiple related changesets may be grouped (i.e. fix or later continuation on an earlier commit) - Voting on a group of changes for categorizing the group as either * to be backported * not to be backported * maybe backported when more complete (no default until some opinions have been voiced) - Voting on a group MAY be reopened later on request - A backport gets reverted if it's status gets changed So, for changeset id, I suggest we use the revision id of the commit of a change to trunk. bzr doesn't yet, but will soon, be able to report on 'has been backported' by the use of cherry pick merges. Beyond that bzr really has nothing build around this, but it looks like an interesting thing to build and have. just trying to figure out how much bzr can support this, an how much needs to be built externally in separate trackers. The simple changeset framework we used for CVS is far from perfect and do not 100% reflect the above requirements, but still worked out reasonably well making sure that changes flows nicely and orderly from HEAD branches down to the active stable branches. We now need to get a similar workflow running for the bzr setup.. I'd probably start with the cvs one but use bzr's superior facilities for obtaining changesets. I thought I understood that 'bzr' encouraged the fix on the old rev and forward port model over backporting / cherry picking? In the style described at: http://www.venge.net/mtn-wiki/DaggyFixes Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH7FHV+gerLs4ltQ4RAugMAKCwXMnoLMtLySsn1eUOsBwk1ec7FgCgiXUL A3AOX4rqlhZJrvuyXCEABz4= =gLzm -END PGP SIGNATURE-
Re: bzr stable branch maintenance and backporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Collins wrote: On Thu, 2008-03-27 at 22:03 -0400, Tres Seaver wrote: I thought I understood that 'bzr' encouraged the fix on the old rev and forward port model over backporting / cherry picking? In the style described at: http://www.venge.net/mtn-wiki/DaggyFixes I think that daggyfixes is the tail shaking the dog. Folk usually don't know how far back a problem goes when they realise a problem exists; where the fix exists in the global revision dag is a technical issue for vcs authors, it should not be something code authors need to think about. OK. I had the impression that bzr's model was branch happy (compared to CVS / SVN), which would seem to me to make forward porting more attractive. For instance, in supportig Zope2, we often need to do a fix across multiple supported releases: e.g., if somebody reported a security issue today, we might end up releasing fixes for Zope 2.8 and 2.9, as well as 2.10 (the currently released branch) and 2.11 (the almost-ready-for-prime-time branch). I've even done one fix in this configuration for 2.7 (because there are a large number of production systems on 2.7, including a couple of my clients). My experience with such fixes indicates that it is much easier to fix the oldest stuff, and than forward port, compared to fixing the trunk, and then backporting. That made the daggy fixes model seem quite natural to me. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH7FdB+gerLs4ltQ4RAkmhAKCm+rGNEcIicIebAaxNnfj++c4uRwCgscMD 3ny2d8pBxxPrFWmXKm3Z+H8= =maXL -END PGP SIGNATURE-
Re: squid-3 vs 2.6
features in a stable stock build. The next - and pressing - priority for the community must surely be Obsoleting Squid 2 before that time runs out. Would everyone on this list support the following: 1. No more 2.x development - new features must be against 3.x 2. Release 3.0.STABLE as quickly as possible (stability is priority, still may lack features from 2.6) 3. Release 3.1 soon after that (feature complete, 2.6 is obsoleted) I feel that if we don't put 2.x development finally to rest, 3.x will never be allowed to overtake it, which is in nobody's interest. The dilution of effort is also pretty shameful. And I second the assessment that 3.0 is quite stable now. We should unite behind it! +1 for this plan. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEnKkn+gerLs4ltQ4RAlTpAKCIyeHxBXlqlp5pvIBPL3ReZuO7SACgunXG agAKSJQhG2EXNUWQzMJUuQ8= =AHBE -END PGP SIGNATURE-
Re: SourceForge CVS online again, almost.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henrik Nordstrom wrote: sön 2006-05-14 klockan 15:11 -0400 skrev Tres Seaver: The squid3 trunk: $ cat CVS/Root :pserver:[EMAIL PROTECTED]:/cvsroot/squid $ cat CVS/Repository squid3 $ cat CVS/Tag cat: CVS/Tag: No such file or directory Why are you getting the trunk from devel.squid-cache.org? If you want the trunk then you should be using the main CVS repository.. I found the CVS_ROOT from *somewhere* on the website. I've since checked out the sources using: $ cvs -d :pserver:[EMAIL PROTECTED]:/squid co \ -d squid3-trunk squid3 and now can't get any reply from 'cvs -q up -AdP' after running the bootstrap. But it does indeed look like the .cvsignore files could need an update. But this is unrelated to the change of CVS servers from what I can tell.. There also seem to be some automake issues at the moment.. make distclean is failing for me leaving quite a bit of stuff around.. BTW, 'make check' fails on the trunk, too, with a linking problem in the 'http_range_test' executable. Known error not related to the CVS servers.. OK, is there a bugzilla entry for it? I threw that in because I happened to notice the failure as 'make check' completed while I was composing the mail. Note that having tests in a known borked state is a strong disincentive for getting non-core folks to help with the release: we can't know whether any tinkering we try has broken something if the tests don't run cleanly beforehand. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEaMqs+gerLs4ltQ4RArUBAJkBCuLxfFR8UrrSTBxZAL96YD5yywCdHxw1 56MGKStkpChmfTjlLONfZ9I= =KiYq -END PGP SIGNATURE-
Self-introduction
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am a self-employed developer whose primary interest in Squid is in deploying it as a reverse proxy in front of dynamic web applications (typically implemented in Zope). I am particularly interested in making ESI work (again): I was one of the engineers at Zope Corp. who worked with Robert Collins on the sponsored development of ESI (now in Squid3). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEaMpK+gerLs4ltQ4RAvuXAKC0FJ9KzDBfs8d0ce4KBjwikcQCPgCaAwma St8ZJzK2ALFXlvfP8Z+rN3s= =QCtL -END PGP SIGNATURE-
Re: SourceForge CVS online again, almost.
/negotiate/.dirstamp ? src/auth/ntlm/.deps ? src/auth/ntlm/.dirstamp ? src/fs/aufs/.deps ? src/fs/coss/.deps ? src/fs/diskd/.deps ? src/fs/null/.deps ? src/fs/ufs/.deps ? src/repl/heap/.deps ? src/repl/lru/.deps ? src/tests/.deps ? src/tests/.dirstamp ? src/tests/.libs ? src/tests/testACLMaxUserIP ? src/tests/testAuth ? src/tests/testBoilerplate ? src/tests/testHeaders ? src/tests/testHttpRequest ? src/tests/testStore ? src/tests/testString ? src/tests/testURL ? src/tests/testUfs ? test-suite/.dirstamp ? test-suite/.libs ? test-suite/debug ? tools/.deps ? tools/.libs ? tools/Makefile ? tools/Makefile.in ? tools/cachemgr.cgi ? tools/squidclient I don't recall seeing that kind of spew before. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEZ2Dc+gerLs4ltQ4RAoaAAJ9QpD04Y/7MCEBLZTMUC2HKH6B+BwCePEm5 Sd4F3UtnNinEj6vqkqM42G4= =tzu3 -END PGP SIGNATURE-
Re: SourceForge CVS online again, almost.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henrik Nordstrom wrote: sön 2006-05-14 klockan 12:54 -0400 skrev Tres Seaver: A lot of '.cvsignore' stuff is broken now. For instance, after doing a fresh checkout and building, I have the following output: $ cvs -q up -AdP ? libtool Which branch is this? The squid3 trunk: $ cat CVS/Root :pserver:[EMAIL PROTECTED]:/cvsroot/squid $ cat CVS/Repository squid3 $ cat CVS/Tag cat: CVS/Tag: No such file or directory $ cvs status bootstrap.sh === File: bootstrap.sh Status: Up-to-date Working revision:1.20 Repository revision: 1.20/cvsroot/squid/squid3/bootstrap.sh,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) BTW, 'make check' fails on the trunk, too, with a linking problem in the 'http_range_test' executable. I tried hacking on the (generated) Makefile, but finally gave up in despair. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEZ4DW+gerLs4ltQ4RAtauAJ9jsafN8KDz0z28lmOe2RFiWkLbtgCgjXM1 +bHozQo2Y1NhH+mwOY1Ojfw= =gyE7 -END PGP SIGNATURE-
Re: Squid-3.0.PRE4 release plan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Doug Dixon wrote: Hi Guido I agree it would be nice to release a trustworthy Squid-3.0.PRE4. Three things however: 1) Our aim is not to produce a PRE4 of a known high quality, but to produce a PRE4 that is as good as it can be by the deadline. 2) I picked the bugs on the basis of their severity as described in Bugzilla. If there are other bugs (it sounds like there are) that fall into the severe and blocker categories, it's important that we go through and make sure the severity field is set correctly. 3) While I'm happy to swap bugs in and out of the todo list, I don't want it to grow demoralisingly large for the deadline we have. It's important to release something. Going through the bugs you have flagged up: 1089 (Possible instability on aborted POST/PUT requests) - patched in 2.5 - is this an easy port? Also, is it related to 772 which is already PRE4? 1465 (assertion failed: mem_node.cc:65: n-write_pending) - yeah sounds bad 1125 (memCopy: could not find start of [337,4433)) - yeah looks like a much-reported bad one, and I *think* is already PRE4 in the guise of 1028 975 (Long document containing ESI includes crashes squid) - looks pretty important to ESI 1088 (Segmentation fault in string handling of ESI) - looks pretty important to ESI 801 (with netfilter - segfault) - pretty specific usage here? 1468 (Crash on HttpHdrRange.cc line 568: assertion failed on valid) - yeah sounds bad 1494 (asserts crash squid too often) - fair complaint, a bit vague, but we should look at it 1200 (HTTP Response Splitting attack) - patched in 2.5 - is this an easy port? 1265 (httpReadReply: Excess data from ... can be silenced in many cases) - patched in 2.5 - is this an easy port? As I say, I am happy to manipulate the list, especially in the first few days. So how about this: First, I think we should probably push the ESI bugs forward to PRE5. Second, hopefully the bugs above that have 2.5 patches can be forward ported quite easily - so I'll add them. Bugs to potentially add to the list: * 1089 (PATCH25) *1465 * 1125 (although, is this really 1028 which is already in there?) * 1468 * 1200 (PATCH25) * 1265 (PATCH25) Bugs to potentially remove from the list: * 942 (squid-3.0-PRE3-20040309 uncached 304's broken) * 897 (Extra CRLF Added After Headers) * 951 (Assert failure in ESIInclude.cc:563: parent.getRaw()) Are we happy to defer ESI stuff (951, 975, 1088) to PRE5? Both ESI issues look to be symptoms of the same bug, given the backtraces: - In #975: #4 0x080a0263 in ESICustomParser::parse (this=0x85787d8, \ dataToParse=0x0,lengthOfData=1396) at ESICustomParser.cc:97 - In # 1088: #6 0x0809ffef in ESICustomParser::parse(char const*, unsigned, bool)\ (this=0x859f0b8, dataToParse=0xb6f0d064 on ...) \ at ESICustomParser.cc:97 Given that the module doesn't even *have* such a line any longer, we can probably back-burner the bugs (even mark as 'WORKSFORME' or something). We really need a testcase which includes the triggering data. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEX1XC+gerLs4ltQ4RAkTjAKCtVNNKU/u646zSZsMYIGf55/6g8wCgw5Ok S1c7IJqo0oaI0YihYYcNZXA= =VMAT -END PGP SIGNATURE-
Re: so what is involved in calling squid-3.0 'stable'?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duane Wessels wrote: My own criteria: be able to deploy Squid3 with ESI as a reverse accelarator under real load without it falling over (I don't run Squid as a forward-cache at all). Can somebody point to a current how to help with Squid3 development document? E.g., I don't even know how to get a current checkout any longer (arch / bzr / cvs, whatever). You can get daily tarball snapshots from http://www.squid-cache.org/Versions/v3/3.0/ If you would rather, you can also use CVS # export CVSROOT=:pserver:[EMAIL PROTECTED]:/squid # cvs login (anoncvs/anoncvs) # cvs checkout squid3 See also http://dokuwiki.squid-cache.org/dev/cvsinstructions If you utilize CVS then you have to run 'bootstrap.sh' from the top directory to create all the Makefile.in's. This gets a little yucky because numerous and certain autotools packages are necessary. Also you may have to run bootstrap.sh from time to time as you develop, ie if you have a yet-uncommitted Makefile.am change. Thanks, I was able to get a checkout built. I'm running Ubuntu Breezy, and so had to install a suitably-recent automake (the default for Ubunutu is 1.4; I installed 'automake1.9'): $ cd ~/projects $ cvs -d :pserver:[EMAIL PROTECTED]:/squid login ... $ cvs -d :pserver:[EMAIL PROTECTED]:/squid co \ -d squid3-trunk squid3 ... $ cd squid3-trunk $ ./bootstrap.sh ... $ ./configure \ --disable-inline --enable-esi --enable-x-accelerator-vary ... $ make check ... And all tests pass except some down in the bowels of the 'cppunit' stuff. I haven't yet tried to run the Squid as an accelerator, but will play with that later this week. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFETlBg+gerLs4ltQ4RAvkdAKCw07IlESFI9MTYdKn+PJlp6J/0QQCglNZm ELIBhphdDVRiYuaH14ojSDA= =BdJo -END PGP SIGNATURE-
Re: about the squid arch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henrik Nordstrom wrote: On Fri, 30 Sep 2005 [EMAIL PROTECTED] wrote: Sorry,who can tell me how i can get an overview of squid.It is a complex giant project to a tyro like me. The beginning of the programmers guide tries to give a overview of the main components. Is there someone have a idea of squid's archtecture? Yes. or tell me what i can do.I have read the Programmers Guide but failed to grasp the main points. The main points you need to grasp are: - Cooperative multitasking by callback events. Instead of waiting for something to happen callbacks is used to signal that a certain event has taken place; network data available, DNS lookup completed, helper has returned answer etc... - The existence of the main select loop, where most callbacks gets registered to get called when there is activity on a network connection. Then from there is a number of different subcomponents to look at depending on what part interest you most. I think it would be fair to describe the architecture around the main select loop is an instance of the Reactor pattern, as documented at: http://www.cs.wustl.edu/~schmidt/PDF/reactor-siemens.pdf Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDPcqN+gerLs4ltQ4RAsRYAKDFKf3OS1pzy2/q5kNviuuYBIOCwACgiEdH jyC8vbrSxq7hqmW6cXJTQRY= =3T36 -END PGP SIGNATURE-
Re: Authenticator in python makes Squid hang
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Giovanni P. Tirloni wrote: Hi, I created a small authenticator in Python that connects to a MySQL database. It's working fine in the command line but when I ask Squid to enforce the password it hangs. There are no log entries in access.log regarding the URL I asked. And in cache.log I see the following: 2005/09/13 09:19:43| aclCheck: checking 'http_access allow password' 2005/09/13 09:19:43| aclMatchAclList: checking password 2005/09/13 09:19:43| aclMatchAcl: checking 'acl password proxy_auth REQUIRED' 2005/09/13 09:19:43| aclMatchAclList: no match, returning 0 2005/09/13 09:19:43| aclCheck: checking password via authenticator Nothing else happens and I've to close Firefox, try another URL, answer the user/password screen and it hangs again. See below the authenticator on the command line: # ./squid_mysql_auth.py abc 123 ERR test ERR bs2 123 OK bs2 111 ERR ^C My code is available at http://tirloni.org/squid/squid_mysql_auth.py (and md5crypt.py by Michal Wallace). Any sugestion? Run python with '-u' (unbuffered stdin / stdout). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDJuwb+gerLs4ltQ4RAkSrAKCTrsvClSYIa4tVzaMsT+Mg1cePqgCfVLe1 8Nl+ruLq+pVixI97vWHmlK4= =SfMC -END PGP SIGNATURE-
Re: Squid Capacity Plan analysis
Muthukumar wrote: Is there any specific analysis or research on capacity planning with squid. I got a thread as, http://www.squid-cache.org/mail-archive/squid-users/199912/0508.html Which is discussion about squid capacity planning. But I couldnot access the links prescribed there. Is squid dev team maintaining records on this? Thanks for your help. SwellTech has a whitepaper on it: http://www.swelltech.com/support/pdfs/sizecache.pdf Tres. -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.com
