Re: X-Vary-Options patch
can you please send the TAGs what i made change in squid.conf Robert Collins wrote: On Fri, 2008-02-08 at 16:26 +1100, Tim Starling wrote: The added features of the patch are conditional, and are enabled by the configure option --enable-vary-options. Unless there is non-trivial process required for regular vary headers with this enabled, I don't think it needs to be optional. -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. -- View this message in context: http://www.nabble.com/X-Vary-Options-patch-tp15349937p15495250.html Sent from the Squid - Development mailing list archive at Nabble.com.
Re: 3.1 steps forward
Adrian Chadd wrote: On Fri, Feb 15, 2008, Amos Jeffries wrote: Sorry if I was obtuse. I meant that you are the expert on this one. Are you able to re-locate that mysterious branch and estimate when you will have time to sync and push it to HEAD? squid3_logdaemon have you fixed the AddrInfo leak? :) A better bypass is now in testing. Hopefully I will have some time tomorrow to run it through the hoops properly. Amos -- Please use Squid 2.6STABLE17+ or 3.0STABLE1+ There are serious security advisories out on all earlier releases.
Re: eCAP: expose Squid or link with eCAP lib?
Hi, Alex Rousskov wrote: 1) Expose Squid internals: Publish/install Squid headers and libraries to give direct access to Squid resources. This approach will most likely require installing pretty much all headers because the module may need to use many Squid services (e.g., DNS lookups) and because of the dependencies between Squid headers. 2) Link with an eCAP library: Implement a Squid-independent eCAP library that Squid and modules will build with to get connected to each other. This way, Squid does not have to publish any of its headers (the library does). This approach may simplify Squid header management and even allow integration with other proxies, but it is more work because it is a stand-alone library and because Squid would have to translate between internal Squid types and eCAP library types. Since the eCAP interface/library is released, it will not be easy to make changes on it any more. Since the eCAP interface/api is released, a number of projects will start using this interface (this is the goal of the eCAP ). Any change on eCAP interface will hurt these projects. This will cause problems in the main squid development. What will happen if the correction of a bug, requires an extra argument in an interface function? An other example is the http headers related code/api which already exists in squid3. All developers agree that the http parser must rewritten which maybe requires change the HttpHeaders api too The second path looks safer but the decision depends on the development time the squid developers (mainly Alex) can give. Also maybe has a performance penalty. Regards, Christos
Re: eCAP: expose Squid or link with eCAP lib?
Tsantilas Christos wrote: Hi, Alex Rousskov wrote: 1) Expose Squid internals: Publish/install Squid headers and libraries to give direct access to Squid resources. This approach will most likely require installing pretty much all headers because the module may need to use many Squid services (e.g., DNS lookups) and because of the dependencies between Squid headers. 2) Link with an eCAP library: Implement a Squid-independent eCAP library that Squid and modules will build with to get connected to each other. This way, Squid does not have to publish any of its headers (the library does). This approach may simplify Squid header management and even allow integration with other proxies, but it is more work because it is a stand-alone library and because Squid would have to translate between internal Squid types and eCAP library types. Since the eCAP interface/library is released, it will not be easy to make changes on it any more. Since the eCAP interface/api is released, a number of projects will start using this interface (this is the goal of the eCAP ). Any change on eCAP interface will hurt these projects. This will cause problems in the main squid development. What will happen if the correction of a bug, requires an extra argument in an interface function? This is not such a large problem as it seems. A published library has a version-number assigned to it is libsquidecap1.1 (for 1st release of squid ecap library) Major changes such as entirely cutting or adding features to the API require a new version. Minor changes such as parameters in a bug fix, only require that the old function remains for its users with some bug-compat wrapper to the new safe call (deprecated and often marked to be removed in next big release). C++ handles overloading with different parameters natively so that is a non-issue in most cases. An other example is the http headers related code/api which already exists in squid3. All developers agree that the http parser must rewritten which maybe requires change the HttpHeaders api too This is very close to being a blocker for eCAP. Unless the eCAP developer is willing to re-write v2 ecap after the Http* classes change. The second path looks safer but the decision depends on the development time the squid developers (mainly Alex) can give. Also maybe has a performance penalty. Wrapper calls most probably do have some penalties. With increasing delays on back-compat wrappers-on-wrappers as time (and changes) go by if they are not culled out. BUT, those penalties are born by the clients and only badly effect those who do not to maintain their programs well enough to move to the new API calls. Amos -- Please use Squid 2.6STABLE17+ or 3.0STABLE1+ There are serious security advisories out on all earlier releases.
