On 9/24/2012 11:46 AM, Amos Jeffries wrote:
Haven't heard anything about this is a while. How is this project going?
Well it's holidays here now so I took a small stop to breath.
we had one just ended and 2\3 in the way so it leaves small amount of time.
and some family stuff on the way so I
On 09/08/2012 01:36 AM, Alex Rousskov wrote:
On 09/07/2012 01:32 PM, Eliezer Croitoru wrote:
On 09/07/2012 05:10 PM, Alex Rousskov wrote:
I am not sure what option you are referring to in the above. The
Store::get(key) API I have described is not optional -- it is the
primary
On 9/09/2012 4:19 a.m., Alex Rousskov wrote:
On 09/07/2012 09:13 PM, Amos Jeffries wrote:
Also, any revalidation requests done later must be done on the
original request URL. Not the stored URL nor the potentially different
current client request URL.
This sounds like a very important point
On 09/06/2012 03:58 AM, Amos Jeffries wrote:
I don't think there is anything which needs new cache_cf.cc code. The
parsing side if things is identical for url_rewrite_*. The different
defaults and locations are all coded in cf.data.pre ...
yes indeed but the actual effect comes from the
On 10.09.2012 04:56, Eliezer Croitoru wrote:
On 09/06/2012 03:58 AM, Amos Jeffries wrote:
I don't think there is anything which needs new cache_cf.cc code.
The parsing side if things is identical for url_rewrite_*. The
different defaults and locations are all coded in cf.data.pre ... yes
On 09/07/2012 09:13 PM, Amos Jeffries wrote:
Also, any revalidation requests done later must be done on the
original request URL. Not the stored URL nor the potentially different
current client request URL.
This sounds like a very important point that could justify storing the
original
On 09/06/2012 09:04 PM, Alex Rousskov wrote:
On 09/05/2012 06:58 PM, Amos Jeffries wrote:
FWIW, I have not reviewed the store_url_rewrite code in Squid2 so I
cannot answer the questions related to how it was done.
I can suggest ways of doing this in Squid3, but since somebody already
On 09/07/2012 06:20 AM, Eliezer Croitoru wrote:
On 09/06/2012 09:04 PM, Alex Rousskov wrote:
The biggest question for me is why Squid2 code was storing multiple
URLs with the cached object (if it was).
Why cannot Store just work with the [rewritten] URL given to it and
ignore the fact that
On 09/07/2012 05:10 PM, Alex Rousskov wrote:
I am not sure what option you are referring to in the above. The
Store::get(key) API I have described is not optional -- it is the
primary way of detecting a hit.
+1 to use the api.
are we talking about the Store::Root().get ?
I was just
On 09/07/2012 01:32 PM, Eliezer Croitoru wrote:
On 09/07/2012 05:10 PM, Alex Rousskov wrote:
I am not sure what option you are referring to in the above. The
Store::get(key) API I have described is not optional -- it is the
primary way of detecting a hit.
+1 to use the api.
On 8/09/2012 7:38 a.m., Eliezer Croitoru wrote:
On 09/07/2012 05:10 PM, Alex Rousskov wrote:
I am not sure what option you are referring to in the above. The
Store::get(key) API I have described is not optional -- it is the
primary way of detecting a hit.
+1 to use the api.
are we
On 6/09/2012 11:00 p.m., Eliezer Croitoru wrote:
I had a *smalll* issue with my storage so I'm forced to start from
almost scratch.
I previously worked on the 3.2.1 latest stable sources and I am
wondering on where to start now?
start on head? stable?
Eliezer
3.HEAD please.
Amos
I had a *smalll* issue with my storage so I'm forced to start from
almost scratch.
I previously worked on the 3.2.1 latest stable sources and I am
wondering on where to start now?
start on head? stable?
Eliezer
On 09/05/2012 06:58 PM, Amos Jeffries wrote:
On 06.09.2012 11:58, Eliezer Croitoru wrote:
We can pause there for the infrastructure to look fine before moving on
to the store details. I've been waiting on assistance from Henrik or
Alex on that for a while. They are the ones who know the
On 9/5/2012 8:00 AM, Amos Jeffries wrote:
On 5/09/2012 4:10 p.m., Eliezer Croitoru wrote:
I'm reading some code (will take a while) to maybe get a functional
store_url_rewrite for squid3+.
Actually i was thinking about it a lot and the process should be very
simple:
use some stdin+stdout like
On 9/5/2012 9:56 AM, Eliezer Croitoru wrote:
any leads,?
Well there is a nice progress.
I reviewed the 2.7 store_url_rewrite and I divided the task into more
detailed smaller tasks.
1. Research the url_rewrite interface code and Introduce a modified
version of url_rewrite as
On 06.09.2012 11:58, Eliezer Croitoru wrote:
On 9/5/2012 9:56 AM, Eliezer Croitoru wrote:
any leads,?
Well there is a nice progress.
I reviewed the 2.7 store_url_rewrite and I divided the task into more
detailed smaller tasks.
FTR: squid-2.7 ports are exempted as suitable in most cases for
OK,
it seems we are getting to somewhere.
i know how to patch using command but what are the proper one to get a
patch file to be run later? will look into it.
Eliezer
On 9/6/2012 3:58 AM, Amos Jeffries wrote:
On 06.09.2012 11:58, Eliezer Croitoru wrote:
On 9/5/2012 9:56 AM, Eliezer
On 06.09.2012 13:23, Eliezer Croitoru wrote:
OK,
it seems we are getting to somewhere.
i know how to patch using command but what are the proper one to get
a patch file to be run later? will look into it.
If you are using diff:
diff -u orig_code/ new_code/ output_file.patch
If you are
On 9/6/2012 4:37 AM, Amos Jeffries wrote:
On 06.09.2012 13:23, Eliezer Croitoru wrote:
OK,
it seems we are getting to somewhere.
i know how to patch using command but what are the proper one to get
a patch file to be run later? will look into it.
If you are using diff:
diff -u orig_code/
I'm reading some code (will take a while) to maybe get a functional
store_url_rewrite for squid3+.
Actually i was thinking about it a lot and the process should be very
simple:
use some stdin+stdout like for url_rewrite interface for starter.
i think this is can be done pretty fast if someone
On 5/09/2012 4:10 p.m., Eliezer Croitoru wrote:
I'm reading some code (will take a while) to maybe get a functional
store_url_rewrite for squid3+.
Actually i was thinking about it a lot and the process should be very
simple:
use some stdin+stdout like for url_rewrite interface for starter.
or effectiveness in the real world it may be
negligible. However there are situations when a connection is idle: when
waiting for a proxy to fetch a page from somewhere else, when holding a
connection open using keep-alive.
At any rate, it was a desired feature on the Squid 3 roadmap and was
already
On 10/13/2010 04:21 AM, Peter Payne wrote:
BENCHMARKS
Firstly, I wanted to address the benchmark questions as it made me
curious as to whether there really was an advantage in using /dev/poll.
I used the Apache Bench tool (that comes with HTTPD) to do my benchmarks.
I compiled a 32-bit
.
Regards
Henrik
The rest being minimal basic plumbing. I'm taking this as a second vote. :)
Applied to Squid-3 as r10946. Thank you Peter.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.8
Beta testers wanted for 3.2.0.2
Hello Amos,
in response to your comments.
BENCHMARKS
Firstly, I wanted to address the benchmark questions as it made me
curious as to whether there really was an advantage in using /dev/poll.
I used the Apache Bench tool (that comes with HTTPD) to do my benchmarks.
I compiled a 32-bit
Hello Amos,
apologies to the dev list for what must appear to be spamming.
Please use the attached version of the file. It has a minor performance
tweak (only set events that have changed if not clearing any events).
Compiled using CC=/tool/sunstudio12/bin/cc and tested again using Apache
ons 2010-10-13 klockan 15:40 +0100 skrev Peter Payne:
Hello Amos,
apologies to the dev list for what must appear to be spamming.
No apologies needed. We are all for release early an often, and
discussing code is what this list is for.
Regards
Henrik
On Wed, 13 Oct 2010 15:40:22 +0100, Peter Payne sourcefo...@pirosa.co.uk
wrote:
Hello Amos,
apologies to the dev list for what must appear to be spamming.
Completely on topic. No apologies needed.
Please use the attached version of the file. It has a minor performance
tweak (only set
ons 2010-10-13 klockan 22:25 + skrev Amos Jeffries:
+1 from me with merge tweaks.
Unless anyone has objections I will commit with tweaks at the next
opportunity.
No objection from me. But have not reviewed the changes outside
comm_devpoll.cc.
Regards
Henrik
Hello Amos,
thank you for your response. Please find attached the four files in
question.
Companies to mention as sponsors are BBC (UK), Siemens IT Solutions and
Services (UK).
Credit to Peter Payne, Pirosa Limited UK (no e-mail please).
Squid bug 3057 was raised by another member of
On Mon, 11 Oct 2010 14:58:34 +0100, Peter Payne sourcefo...@pirosa.co.uk
wrote:
Hello Amos,
thank you for your response. Please find attached the four files in
question.
Companies to mention as sponsors are BBC (UK), Siemens IT Solutions and
Services (UK).
Credit to Peter Payne,
Dear Mailing List,
I have a contribution to make, a C++ file (and autoconf patches) for
/dev/poll Solaris support, ported from Squid-2 and in use on the BBC
(UK) estate managed by Siemens UK with permission from the BBC to
publish to the Squid open-source project.
I've not contributed to
On 08/10/10 23:13, Peter Payne wrote:
Dear Mailing List,
I have a contribution to make, a C++ file (and autoconf patches) for
/dev/poll Solaris support, ported from Squid-2 and in use on the BBC
(UK) estate managed by Siemens UK with permission from the BBC to
publish to the Squid open-source
I read a while ago that this would only be available in squid 3.2, but
wonder if there is already some implementation because I was thinking
about doing that but was wondering if there is already some effort.
--
osmano807
Joaquim Pedro
Joaquim Pedro França Simão wrote:
I read a while ago that this would only be available in squid 3.2, but
wonder if there is already some implementation because I was thinking
about doing that but was wondering if there is already some effort.
It was planned to be ported along with the other
Hello,
HTTP compliance results for Squid 3.0.23, 3.1.16, and trunk r10264
have been uploaded to http://wiki.squid-cache.org/Features/HTTP11
We tried to preserve the old results intact for this update and just
added new stuff. Going forward, we will polish the spreadsheet and
probably remove
On 01/28/2010 04:42 PM, Mark Nottingham wrote:
FWIW, I have an XSLT stylesheet that can format the results
pleasantly; it could be a starting point for something automated.
Please share if you can.
Thank you,
Alex.
On 29/01/2010, at 12:34 AM, Amos Jeffries wrote:
Robert Collins wrote:
On 01/28/2010 06:34 AM, Amos Jeffries wrote:
Robert Collins wrote:
On Wed, 2010-01-27 at 22:49 -0700, Alex Rousskov wrote:
c) Co-Advisor currently only tests MUST-level requirements. Old Robert's
checklist contained some SHOULD-level requirements as well. I see that
Sheet1 on the
On Wed, 2010-01-27 at 22:49 -0700, Alex Rousskov wrote:
c) Co-Advisor currently only tests MUST-level requirements. Old Robert's
checklist contained some SHOULD-level requirements as well. I see that
Sheet1 on the spreadsheet has SHOULDs. Are we kind of ignoring them (and
Sheet1) for now,
Robert Collins wrote:
On Wed, 2010-01-27 at 22:49 -0700, Alex Rousskov wrote:
c) Co-Advisor currently only tests MUST-level requirements. Old Robert's
checklist contained some SHOULD-level requirements as well. I see that
Sheet1 on the spreadsheet has SHOULDs. Are we kind of ignoring them
FWIW, I have an XSLT stylesheet that can format the results pleasantly; it
could be a starting point for something automated.
On 29/01/2010, at 12:34 AM, Amos Jeffries wrote:
Robert Collins wrote:
On Wed, 2010-01-27 at 22:49 -0700, Alex Rousskov wrote:
c) Co-Advisor currently only tests
On 01/09/2010 04:10 AM, Amos Jeffries wrote:
Alex Rousskov wrote:
On 09/12/2009 05:36 AM, Amos Jeffries wrote:
Updating the checklist today I again wonder if we can repeat the step
from 2.7 and enable HTTP/1.1 on requests sent to servers
As far as I can see the missing bits 3.2 needs to take
Alex Rousskov wrote:
On 09/12/2009 05:36 AM, Amos Jeffries wrote:
Updating the checklist today I again wonder if we can repeat the step
from 2.7 and enable HTTP/1.1 on requests sent to servers
As far as I can see the missing bits 3.2 needs to take that step are:
- reject http-Upgrade
On 09/12/2009 05:36 AM, Amos Jeffries wrote:
Updating the checklist today I again wonder if we can repeat the step
from 2.7 and enable HTTP/1.1 on requests sent to servers
As far as I can see the missing bits 3.2 needs to take that step are:
- reject http-Upgrade requests from clients.
trying to fix bug 2176 I think I see a
clean way to create expect-100 handling in Squid-3.
If someone with more store experience can point out to me how to reset
the StoreEntry properly after receiving and passing on a reply we can
accept and process the 100 reply and then reset it for the actual
Amos Jeffries wrote:
Since we have no central place where the headers are upgraded I've had
to skip porting the upgrade_http0.9 hack in Squid-2 and go straight to
accepting ICY protocol as an accepted response protocol and handling it.
Somewhat primitive for now. It's limited to parsing and
that header internally with HTTP/0.9 as
version. The version is overridden anyway when the response is composed.
Aye. I read the patch many times ;)
Squid-3 stores them as:
ICY-status
ICY+HTTP-headers (new HTTP ones last due to appending)
Code which does upgrading on purely version numbers
Hi Henrik,
Sorry again for the delay ... :-(
c:\work\vc_string\vs_string.cc : see declaration of 'size_t'
c:\work\vc_string\vs_string.cc(34) : error C2057: expected constant
expression
Good. so it seems the test case worked.
now replace std with testcase and try again, both
Hi Henrik,
Odd... std::string::npos is declared as follows:
namespace std;
templateclass _Elem,
class _Traits,
class _Ax
class basic_string
: public _String_val_Elem, _Ax
{
public:
static const size_type npos;
};
tor 2009-09-17 klockan 11:15 +0200 skrev Guido Serassio:
It fails:
vs_string.cc
c:\work\vc_string\vs_string.cc(1) : error C2371: 'size_t' :
redefinition; different basic types
Gah, should have been unsigned long.. but interesting that VS apparently
has size_t built-in. It was declared in
Hi Henrik,
Can you produce a preprocessed source? That's the output of just the
preprocessor, not actual compilarion, comparable to gcc -E option.
Easier to identify what the compiler actually saw that way...
Done. Sorry for the delay, but I'm very busy (as usual ...)
I have placed the
mån 2009-09-14 klockan 11:27 +0200 skrev Guido Serassio:
Done. Sorry for the delay, but I'm very busy (as usual ...)
I have placed the preprocessed source of two failing files
(IpIntercept.cc and QosConfig.cc) here:
http://www.acmeconsulting.it/libip.zip
Odd... std::string::npos is
Updating the checklist today I again wonder if we can repeat the step
from 2.7 and enable HTTP/1.1 on requests sent to servers
As far as I can see the missing bits 3.2 needs to take that step are:
- reject http-Upgrade requests from clients.
- reject Expect-100 requests from clients.
lör 2009-09-12 klockan 23:36 +1200 skrev Amos Jeffries:
Updating the checklist today I again wonder if we can repeat the step
from 2.7 and enable HTTP/1.1 on requests sent to servers
The default in 2.7 is 1.0 still. There is an option to enable 1.1, or
actually three.. (http11 cache_peer
://www.acmeconsulting.it
-Messaggio originale-
Da: Amos Jeffries [mailto:squ...@treenet.co.nz]
Inviato: martedì 1 settembre 2009 10.43
A: Henrik Nordstrom
Cc: Guido Serassio; Robert Collins; squid-dev@squid-cache.org
Oggetto: Re: R: R: R: Squid 3 build errors on Visual Studio - problem
still present
ons 2009-09-02 klockan 21:11 +0200 skrev Guido Serassio:
Hi,
OK, but what next ?
Can you produce a preprocessed source? That's the output of just the
preprocessor, not actual compilarion, comparable to gcc -E option.
Easier to identify what the compiler actually saw that way...
Regards
: Re: R: R: Squid 3 build errors on Visual Studio - problem
still
present
On Sun, 2009-08-30 at 18:13 +0200, Guido Serassio wrote:
Hi,
I don't know what is std::string::npos, and so I don't know what to
look
for
http://www.cplusplus.com/reference/string/string/npos/
It should
Hi,
The patch from Amos fix the warning (not blocking problem), but the
compile problem is still present, and I don't know how to fix it.
Any file including SquidString.h doesn't build with following error:
c:\work\nt-3.0\src\SquidString.h(98) : error C2057: expected constant
expression
The
On Sun, 2009-08-30 at 09:48 +0200, Guido Serassio wrote:
c:\work\nt-3.0\src\SquidString.h(98) : error C2057: expected constant
expression
The offending code is:
const static size_type npos = std::string::npos;
Can you find out what std::string::npos is defined as in your compiler's
On Sun, 2009-08-30 at 18:13 +0200, Guido Serassio wrote:
Hi,
I don't know what is std::string::npos, and so I don't know what to look
for
http://www.cplusplus.com/reference/string/string/npos/
It should be a static const, which is why I'm so surprised you're
getting an error about it.
Hi Amos,
Hi,
Who can help me to fix the following C++ errors on Visual Studio ?
1auth_basic.cc
1c:\work\nt-3.0\src\SquidString.h(97) : error C2057: expected
constant
expression
1../../../src\auth/User.h(39) : warning C4099:
'AuthUserHashPointer' :
type name first seen using
Hi,
Who can help me to fix the following C++ errors on Visual Studio ?
1auth_basic.cc
1c:\work\nt-3.0\src\SquidString.h(97) : error C2057: expected constant
expression
1../../../src\auth/User.h(39) : warning C4099: 'AuthUserHashPointer' : type
name first seen using 'struct' now seen using
Guido Serassio wrote:
Hi,
Who can help me to fix the following C++ errors on Visual Studio ?
1auth_basic.cc
1c:\work\nt-3.0\src\SquidString.h(97) : error C2057: expected constant
expression
1../../../src\auth/User.h(39) : warning C4099: 'AuthUserHashPointer' : type
name first seen using
: squid-dev@squid-cache.org
Betreff: Re: Squid-3 MacOSX IPv6 problems
Oh dear.
Can you provide the config.log generated during build and a full cache.log
from the point of startup through a failed DNS query please?
Amos
--
Please be using
Current Stable Squid 2.7.STABLE6 or 3.0.STABLE17
Oh dear.
Can you provide the config.log generated during build and a full cache.log
from the point of startup through a failed DNS query please?
Amos
-miss' '--enable-default-err-language=templates'
'--enable-fd-config' '--with-filedescriptors=16384' '--with-dl'
'--enable-gnuregex' '--enable-zph-qos' '--enable-ltdl-convenience'
'--prefix=/usr/local/squid31' 'build_alias=i686-apple-darwin'
--with-squid=/Users/raymont/squid-3.HEAD-20090723
Hello again and apologies for the long delays.
If you are still interested in getting Squid-3 to build with IPv6 read on.
The current Squid-3.HEAD snapshots have been stabilized as much as I can
do for now and include a few patches which I believe get split-stack
support you need to build
Hi,
I have a little of free time, and I'm trying to build Squid 3 on
MinGW, but I'm getting the following error:
if /bin/sh ../../libtool --tag=CXX --mode=compile g++
-DHAVE_CONFIG_H -I../.. -I../../include -I../../src
-I../../include -I/usr/include/libxml2 -Werror -Wall
-Wpointer
Serassio Guido wrote:
Hi,
I have a little of free time, and I'm trying to build Squid 3 on MinGW,
but I'm getting the following error:
if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H
-I../.. -I../../include -I../../src -I../../include
-I/usr/include/libxml2
Serassio Guido wrote:
Hi Amos,
At 11.45 31/05/2009, Amos Jeffries wrote:
Someone could help me ?
Regards
Guido
They are declared in the compat/* library. Included through config.h.
compat/compat_shared.h to be exact if you need the definition (but
please only include config.h for the
Hi all,
I've also planned hosting a shared windows dev system on eu, but we
need to secure the necessary OS and devkit licenses first.
On Monday, May 4, 2009, Guido Serassio guido.seras...@acmeconsulting.it wrote:
Hi Alex,
Il 02.13 04/05/2009 Alex Rousskov ha scritto:
Hi Guido,
On 05/05/2009 12:51 AM, Kinkie wrote:
I've also planned hosting a shared windows dev system on eu, but we
need to secure the necessary OS and devkit licenses first.
Securing somebody who will be working on that windows dev system should
come first, I guess. If nobody is going to be
Hi Alex,
Il 02.13 04/05/2009 Alex Rousskov ha scritto:
Hi Guido,
Thanks a lot for the update. It is sad to see the results of many
years of work dissipating and I sympathize with your situation. I wonder
whether the demand for Squid on Windows is just not there OR it is the
current lack of
and Squid 3.
Build environment
Squid should compile on Windows with 3 build environment, but with some limits:
- MinGW+MSYS: full automake/autoconf/libtool/gcc support based on GNU
toolset, but not all functionality (Large file support, IPv6,
mswin_check_ad_group helper, WSAPoll() support
, source code status and a TODO
for both Squid 2 and Squid 3.
Build environment
Squid should compile on Windows with 3 build environment, but with some
limits:
- MinGW+MSYS: full automake/autoconf/libtool/gcc support based on GNU
toolset, but not all functionality (Large file support
please do so.
Though I know python well, I am not comfortable with c/c++. And as I
am a developer myself, can't really supply cash :(
I'll sit back and wait. In the meantime will try to revamp my c/c++
concepts so that I can jump in squid-devel in future.
The roadmap for work on Squid-3
Hi list,
Is there any plans to port storeurl directives from 2.7 to 3.x? I
don't see it in 3.1 beta. One of my plugins (intelligentmirror [1])
depends on it. I am not able to release a version for squid-3.x and most
the distros are shipping squid-3.x now.
[1] http://fedora.co.in
Just for the sake of consistency and preference for better
troubleshooting and testing, are there any CFLAGS that I should be using
during configure and compile of Squid 3HEAD? I was using the same
options I was using with 2.6, which were:
CFLAGS=-DNUMTHREADS=65 -march=nocona -03 -pipe
Take 2: includes initial modularisation (untested; I'll test it at home
this weekend when I get my tproxy box back online) and configure magic
(with placeholders for tproxy4/freebsd.)
http://www.creative.net.au/diffs/20080408-tproxy-fix-2.diff
TODO:
* pull out the capabilities stuff, removing
tis 2008-04-08 klockan 17:59 +1200 skrev Amos Jeffries:
Currently:
fde::flags::transparent == 'intercept/non-intercept'
fde::flags::tproxy == real-transparent/non-transparent
(new) COMM_TRANSPARENT == real-transparent
Their use is currently good for what they do. A small re-naming
tis 2008-04-08 klockan 14:28 +0800 skrev Adrian Chadd:
Take 2: includes initial modularisation (untested; I'll test it at home
this weekend when I get my tproxy box back online) and configure magic
(with placeholders for tproxy4/freebsd.)
On Tue, Apr 08, 2008, Henrik Nordstrom wrote:
tis 2008-04-08 klockan 14:28 +0800 skrev Adrian Chadd:
Take 2: includes initial modularisation (untested; I'll test it at home
this weekend when I get my tproxy box back online) and configure magic
(with placeholders for tproxy4/freebsd.)
On Tue, 2008-04-08 at 15:15 +0200, Henrik Nordstrom wrote:
tis 2008-04-08 klockan 17:59 +1200 skrev Amos Jeffries:
Currently:
fde::flags::transparent == 'intercept/non-intercept'
fde::flags::tproxy == real-transparent/non-transparent
(new) COMM_TRANSPARENT == real-transparent
tis 2008-04-08 klockan 22:17 +0800 skrev Adrian Chadd:
* make sure upstream/peer-forwarded requests aren't thrown to the tproxy
code.
I read the current code as don't do that; its the behaviour I'd like to
maintain. We can always add the functionality later.
Yes, it is not something
On Tue, Apr 08, 2008, Adrian Chadd wrote:
Take 3:
http://www.creative.net.au/diffs/20080408-tproxy-fix-2.diff
* restored the global flag which indicates tproxyness; renamed to
enable_spoof_srv
* moved the tproxy bind stuff into comm.c, with a flag to comm_openex()
* changed forward.c to try
On Tue, 2008-04-08 at 15:15 +0200, Henrik Nordstrom wrote:
tis 2008-04-08 klockan 17:59 +1200 skrev Amos Jeffries:
Currently:
fde::flags::transparent == 'intercept/non-intercept'
fde::flags::tproxy == real-transparent/non-transparent
(new) COMM_TRANSPARENT == real-transparent
creation process, and
* The initialisation code, which in the tproxy-2 case does capabilities
magic.
Adrian
We have come up with a 'final-beta' patch for squid-3 now.
http://treenet.co.nz/projects/squid/patches/tproxy-squid-3_20080407.patch
Just waiting on Laszlo final approval.
It's pretty much
mån 2008-04-07 klockan 23:11 +1200 skrev Amos Jeffries:
We have come up with a 'final-beta' patch for squid-3 now.
http://treenet.co.nz/projects/squid/patches/tproxy-squid-3_20080407.patch
Just waiting on Laszlo final approval.
Some comments...
There should be a general TPROXY define, shared
and fix the tproxy
support in Squid-2 to show how it should be done..
Adrian
On Mon, Apr 07, 2008, Henrik Nordstrom wrote:
m??n 2008-04-07 klockan 23:11 +1200 skrev Amos Jeffries:
We have come up with a 'final-beta' patch for squid-3 now.
http://treenet.co.nz/projects/squid/patches/tproxy-squid
tis 2008-04-08 klockan 01:16 +0800 skrev Adrian Chadd:
In fact, there shouldn't be any LINUX_TPROXY* defines in the main codetree.
There should be a SERVER_SPOOF define which ties in all of the connection
tracking stuff, and a clean cut API for doing TPROXY2/TPROXY4/etc socket
manipulation.
Henrik Nordstrom wrote:
tis 2008-04-08 klockan 01:16 +0800 skrev Adrian Chadd:
In fact, there shouldn't be any LINUX_TPROXY* defines in the main codetree.
There should be a SERVER_SPOOF define which ties in all of the connection
tracking stuff, and a clean cut API for doing TPROXY2/TPROXY4/etc
tis 2008-04-08 klockan 09:57 +1200 skrev Amos Jeffries:
But, baby steps people:
- Get it in
- Get it tested.
- Polish into a class.
So far we are at #1
And I won't approve the change of sprinkling #if LINUX_TPROXY4 over the
code, even if it's just adding to the existing #if..
Get
On Tue, Apr 08, 2008, Henrik Nordstrom wrote:
tis 2008-04-08 klockan 09:57 +1200 skrev Amos Jeffries:
But, baby steps people:
- Get it in
- Get it tested.
- Polish into a class.
So far we are at #1
And I won't approve the change of sprinkling #if LINUX_TPROXY4 over the
On Mon, Apr 07, 2008, Amos Jeffries wrote:
We have come up with a 'final-beta' patch for squid-3 now.
http://treenet.co.nz/projects/squid/patches/tproxy-squid-3_20080407.patch
Just waiting on Laszlo final approval.
It's pretty much:
* adding a COMM_TRANSPARENT flag to comm_openex
Adrian Chadd wrote:
On Mon, Apr 07, 2008, Amos Jeffries wrote:
We have come up with a 'final-beta' patch for squid-3 now.
http://treenet.co.nz/projects/squid/patches/tproxy-squid-3_20080407.patch
Just waiting on Laszlo final approval.
It's pretty much:
* adding a COMM_TRANSPARENT flag
On Mon, Mar 31, 2008, Alex Rousskov wrote:
What about Adrian plans (if I understood them correctly) to add
TPROXY-like support to FreeBSD but not for TPROXY4-like API? Is that a
good enough reason to continue supporting unsupported TPROXY versions?
The FreeBSD API will be almost like the
Between Balabit and TreeNet we have come up with a working TPROXY 4+ patch.
It'll be sent to trunk soon.
The merge It would be a whole lot cleaner and actually less change
overall if we could drop the TPROXY version 2 support from Squid-3.
I know we will likely need to keep the old support
On Tue, Apr 01, 2008, Amos Jeffries wrote:
Between Balabit and TreeNet we have come up with a working TPROXY 4+ patch.
It'll be sent to trunk soon.
The merge It would be a whole lot cleaner and actually less change
overall if we could drop the TPROXY version 2 support from Squid-3.
I
Squid-3.
I know we will likely need to keep the old support in Squid-2. But with
3.1 we will have the option of saying it requires kernel 2.6.2* or later
to run transparent TPROXY.
Comments?
We may be able to provide better comments when we see the current code.
It does not have
1 - 100 of 317 matches
Mail list logo
