Re: [squid-dev] [PATCH] securiy_fake_certv ; aka helpers/ shuffling exemplar

[Amos Jeffries]

On 29/01/2016 4:54 a.m., Alex Rousskov wrote:
> On 01/28/2016 06:55 AM, Amos Jeffries wrote:
>> This patch demonstrates my proposed helpers/ shuffling by updating the
>> demo certificate validator.
>>
>> * creates src/security/certv/ for certificate validation helpers.
>>  To distinguish from certificate generator helpers which would be in
>> src/security/certg/.
> 
> Please consider using more than one letter to distinguish directories
> (e.g., cert_gen and cert_validators).
> 

Okay.

> 
>> +(C) 2012 The Measurement Factory, Author: Tsantilas Christos
> 
> If it helps, you may use the standard Squid boilerplate for Factory
> files and avoid a special CREDITS mention.
> 

:-)

I was actually going to follow up with a request that it be changed to
the BSD 3-clause like the other 'fake' helpers I wrote. That license
better allows/encourages third-party validators to be created from our
helper template than the Squid GPL one, but still need a CREDITS entry.

I'd like to keep license changes separate anyway. And since you have
commit access please do whichever ASAP.


> 
>> +One fake helper that it does not actually perform any
>> +   certificate checks is provided for testing and example code for 
>> writing
>> +   custom helpers.
> 
> s/that it does/that does/
> s/and example code for/and as an example for/
> s/custom helpers/real validators/
> 

Oops, (shame). Thank you.

> 
> I did not audit the path but have no objections (with or without the
> above polishing touches).
> 
> 
> Thank you,
> 
> Alex.
> 


Amos
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Hello and ssl_bump and External ACLs - 4.0.2

[Alex Rousskov]

On 01/28/2016 08:23 AM, Dave Lewthwaite wrote:

> I appreciate it’s been a while but I’m still keen to get to the bottom of 
> this problem.
> 
> I am currently working with nightly squid-4.0.4-20160124-r14504


FYI: Trunk external_acl is pretty much broken with regard to
AccessLogEntry (ALE) usage after trunk r14351 (Support logformat %macros
in external_acl_type format). We are actively working on a fix which
goes beyond the initial patch you have tried. I hope Christos will post
the corresponding patch soon.

Alex.

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Hello and ssl_bump and External ACLs - 4.0.2

[Dave Lewthwaite]

Hi,



I appreciate it’s been a while but I’m still keen to get to the bottom of this 
problem.

I am currently working with nightly squid-4.0.4-20160124-r14504 applying a 
modified patch from earlier in this thread (I had to modify as some of the 
objects have moved around and are accessed differently). This results in the 
same problem, however, I was able to get it all working for normal proxy ports 
(HTTP where clients do CONNECT) by adding this line - 

acl_checklist->al = pipeline.front()->http->al;


Into ConnStateData::startPeekAndSpliceDone() from client_side.cc - the external 
ACL is then correctly evaluated with all the correct fields supplied and the 
splice/bump decision is made correctly.

It doesn’t work for transparent interception however (https_port and IPTables 
redirect) but it’s the ACL checking in this function that goes wrong.

I’m happy to try any suggestions and/or provide debug info etc.

Thanks in advance.

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] [RFC] V6 connectivity testing and dns_v4_first auto setter bash script.

[Eliezer Croitoru]

I wrote a tiny bash script that I will later push into the CentOS RPMs 
and was wondering about pushing it into the squid sources.

The source at: http://paste.ngtech.co.il/pxizenek2

It was written for linux but can be modified for FreeBSD and other *NIX 
OS's.
Checks for IPV6 resolution and connectivity(ping6) and changes 
squid.conf dns_v4_first to or or off.

My idea was to run it every time before squid starts\restarts.

What do you think about the idea of testing ipv6 connectivity in general 
before starting squid and about automatically change squid.conf?


Thanks,
Eliezer
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Hello and ssl_bump and External ACLs - 4.0.2

[Christos Tsantilas]

Hi Dave,

 We are working on a patch which solves this problem and other related 
or similar problems. It requires more complex patch than my initial 
patch posted here.



On 01/28/2016 05:23 PM, Dave Lewthwaite wrote:

Hi,



I appreciate it’s been a while but I’m still keen to get to the bottom of this 
problem.

I am currently working with nightly squid-4.0.4-20160124-r14504 applying a 
modified patch from earlier in this thread (I had to modify as some of the 
objects have moved around and are accessed differently). This results in the 
same problem, however, I was able to get it all working for normal proxy ports 
(HTTP where clients do CONNECT) by adding this line -

acl_checklist->al = pipeline.front()->http->al;


Into ConnStateData::startPeekAndSpliceDone() from client_side.cc - the external 
ACL is then correctly evaluated with all the correct fields supplied and the 
splice/bump decision is made correctly.

It doesn’t work for transparent interception however (https_port and IPTables 
redirect) but it’s the ACL checking in this function that goes wrong.

I’m happy to try any suggestions and/or provide debug info etc.

Thanks in advance.



___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] Fix external_acl problems

[Christos Tsantilas]

Hi all,

After the patch r14351 created the following problems:
 - external_acl requires AccessLogEntry but ALE is not available
   in many cases such as ssl_bump ACLs.
 - The %  - In the case of transparent SSL bumping, the patch uses a local 
AccessLogEntry to allow external_acl work with the ssl_bump access list.


 - The slow acls inside Ssl::PeerConnector can not support external_acl 
in the case of PeerPoolMgr


  - Most of the fast acls does not support ALE based acls. I know that 
currently the only ALE based acl is the external_acl, which is slow acl, 
but my opinion is that it is not bad idea  to support cases the 
external_acl result is stored in cache.


  - Also we need to check and review if the informations passed with 
the ALE is the same passed using the FilledChecklist object. This is not 
obvious.



This is a Measurement Factory project.
Fix external_acl problems after trunk r14351
(Support logformat %macros in external_acl_type format).

The above changes created the following problems:
 - external_acl requires AccessLogEntry but ALE is not available
   in many cases such as ssl_bump ACLs.
 - The %fd, fwdServerClosedWrapper, this);
 
 #if USE_OPENSSL
 if (!request->flags.pinned) {
 const CachePeer *p = serverConnection()->getPeer();
 const bool peerWantsTls = p && p->secure.encryptTransport;
 // userWillTlsToPeerForUs assumes CONNECT == HTTPS
 const bool userWillTlsToPeerForUs = p && p->options.originserver &&
 request->method == Http::METHOD_CONNECT;
 const bool needTlsToPeer = peerWantsTls && !userWillTlsToPeerForUs;
 const bool needTlsToOrigin = !p && request->url.getScheme() == AnyP::PROTO_HTTPS;
 if (needTlsToPeer || needTlsToOrigin || request->flags.sslPeek) {
 HttpRequest::Pointer requestPointer = request;
 AsyncCall::Pointer callback = asyncCall(17,4,
 "FwdState::ConnectedToPeer",
 FwdStatePeerAnswerDialer(::connectedToPeer, this));
 // Use positive timeout when less than one second is left.
 const time_t sslNegotiationTimeout = max(static_cast(1), timeLeft());
 Ssl::PeerConnector *connector = NULL;
 if (request->flags.sslPeek)
-connector = new Ssl::PeekingPeerConnector(requestPointer, serverConnection(), clientConn, callback, sslNegotiationTimeout);
+connector = new Ssl::PeekingPeerConnector(requestPointer, serverConnection(), clientConn, callback, al, sslNegotiationTimeout);
 else
-connector = new Ssl::BlindPeerConnector(requestPointer, serverConnection(), callback, sslNegotiationTimeout);
+connector = new Ssl::BlindPeerConnector(requestPointer, serverConnection(), callback, al, sslNegotiationTimeout);
 AsyncJob::Start(connector); // will call our callback
 return;
 }
 }
 #endif
 
 // if not encrypting just run the post-connect actions
 Security::EncryptorAnswer nil;
 connectedToPeer(nil);
 }
 
 void
 FwdState::connectedToPeer(Security::EncryptorAnswer )
 {
 if (ErrorState *error = answer.error.get()) {
 fail(error);
 answer.error.clear(); // preserve error for errorSendComplete()
 if (CachePeer *p = serverConnection()->getPeer())
 peerConnectFailed(p);
 retryOrBail();

=== modified file 'src/PeerPoolMgr.cc'
--- src/PeerPoolMgr.cc	2016-01-01 00:12:18 +
+++ src/PeerPoolMgr.cc	2016-01-28 15:39:53 +
@@ -113,41 +113,41 @@
 
 Must(params.conn != NULL);
 
 #if USE_OPENSSL
 // Handle SSL peers.
 if (peer->secure.encryptTransport) {
 typedef CommCbMemFunT CloserDialer;
 closer = JobCallback(48, 3, CloserDialer, this,
  PeerPoolMgr::handleSecureClosure);
 comm_add_close_handler(params.conn->fd, closer);
 
 securer = asyncCall(48, 4, "PeerPoolMgr::handleSecuredPeer",
 MyAnswerDialer(this, ::handleSecuredPeer));
 
 const int peerTimeout = peer->connect_timeout > 0 ?
 peer->connect_timeout : Config.Timeout.peer_connect;
 const int timeUsed = squid_curtime - params.conn->startTime();
 // Use positive timeout when less than one second is left for conn.
 const int timeLeft = max(1, (peerTimeout - timeUsed));
 Ssl::BlindPeerConnector *connector =
-new Ssl::BlindPeerConnector(request, params.conn, securer, timeLeft);
+new Ssl::BlindPeerConnector(request, params.conn, securer, NULL, timeLeft);
 AsyncJob::Start(connector); // will call our callback
 return;
 }
 #endif
 
 pushNewConnection(params.conn);
 }
 
 void
 PeerPoolMgr::pushNewConnection(const Comm::ConnectionPointer )
 {
 

[squid-dev] [PATCH] Fix external_acl problems

[Christos Tsantilas]

Hi all,

After the patch r14351 created the following problems:
 - external_acl requires AccessLogEntry but ALE is not available
   in many cases such as ssl_bump ACLs.
 - The %  - In the case of transparent SSL bumping, the patch uses a local 
AccessLogEntry to allow external_acl work with the ssl_bump access list.


 - The slow acls inside Ssl::PeerConnector can not support external_acl 
in the case of PeerPoolMgr


  - Most of the fast acls does not support ALE based acls. I know that 
currently the only ALE based acl is the external_acl, which is slow acl, 
but my opinion is that it is not bad idea  to support cases the 
external_acl result is stored in cache.


  - Also we need to check and review if the informations passed with 
the ALE is the same passed using the FilledChecklist object. This is not 
obvious.



This is a Measurement Factory project.
Fix external_acl problems after trunk r14351
(Support logformat %macros in external_acl_type format).

The above changes created the following problems:
 - external_acl requires AccessLogEntry but ALE is not available
   in many cases such as ssl_bump ACLs.
 - The %fd, fwdServerClosedWrapper, this);
 
 #if USE_OPENSSL
 if (!request->flags.pinned) {
 const CachePeer *p = serverConnection()->getPeer();
 const bool peerWantsTls = p && p->secure.encryptTransport;
 // userWillTlsToPeerForUs assumes CONNECT == HTTPS
 const bool userWillTlsToPeerForUs = p && p->options.originserver &&
 request->method == Http::METHOD_CONNECT;
 const bool needTlsToPeer = peerWantsTls && !userWillTlsToPeerForUs;
 const bool needTlsToOrigin = !p && request->url.getScheme() == AnyP::PROTO_HTTPS;
 if (needTlsToPeer || needTlsToOrigin || request->flags.sslPeek) {
 HttpRequest::Pointer requestPointer = request;
 AsyncCall::Pointer callback = asyncCall(17,4,
 "FwdState::ConnectedToPeer",
 FwdStatePeerAnswerDialer(::connectedToPeer, this));
 // Use positive timeout when less than one second is left.
 const time_t sslNegotiationTimeout = max(static_cast(1), timeLeft());
 Ssl::PeerConnector *connector = NULL;
 if (request->flags.sslPeek)
-connector = new Ssl::PeekingPeerConnector(requestPointer, serverConnection(), clientConn, callback, sslNegotiationTimeout);
+connector = new Ssl::PeekingPeerConnector(requestPointer, serverConnection(), clientConn, callback, al, sslNegotiationTimeout);
 else
-connector = new Ssl::BlindPeerConnector(requestPointer, serverConnection(), callback, sslNegotiationTimeout);
+connector = new Ssl::BlindPeerConnector(requestPointer, serverConnection(), callback, al, sslNegotiationTimeout);
 AsyncJob::Start(connector); // will call our callback
 return;
 }
 }
 #endif
 
 // if not encrypting just run the post-connect actions
 Security::EncryptorAnswer nil;
 connectedToPeer(nil);
 }
 
 void
 FwdState::connectedToPeer(Security::EncryptorAnswer )
 {
 if (ErrorState *error = answer.error.get()) {
 fail(error);
 answer.error.clear(); // preserve error for errorSendComplete()
 if (CachePeer *p = serverConnection()->getPeer())
 peerConnectFailed(p);
 retryOrBail();

=== modified file 'src/PeerPoolMgr.cc'
--- src/PeerPoolMgr.cc	2016-01-01 00:12:18 +
+++ src/PeerPoolMgr.cc	2016-01-28 15:39:53 +
@@ -113,41 +113,41 @@
 
 Must(params.conn != NULL);
 
 #if USE_OPENSSL
 // Handle SSL peers.
 if (peer->secure.encryptTransport) {
 typedef CommCbMemFunT CloserDialer;
 closer = JobCallback(48, 3, CloserDialer, this,
  PeerPoolMgr::handleSecureClosure);
 comm_add_close_handler(params.conn->fd, closer);
 
 securer = asyncCall(48, 4, "PeerPoolMgr::handleSecuredPeer",
 MyAnswerDialer(this, ::handleSecuredPeer));
 
 const int peerTimeout = peer->connect_timeout > 0 ?
 peer->connect_timeout : Config.Timeout.peer_connect;
 const int timeUsed = squid_curtime - params.conn->startTime();
 // Use positive timeout when less than one second is left for conn.
 const int timeLeft = max(1, (peerTimeout - timeUsed));
 Ssl::BlindPeerConnector *connector =
-new Ssl::BlindPeerConnector(request, params.conn, securer, timeLeft);
+new Ssl::BlindPeerConnector(request, params.conn, securer, NULL, timeLeft);
 AsyncJob::Start(connector); // will call our callback
 return;
 }
 #endif
 
 pushNewConnection(params.conn);
 }
 
 void
 PeerPoolMgr::pushNewConnection(const Comm::ConnectionPointer )
 {
 

Re: [squid-dev] Hello and ssl_bump and External ACLs - 4.0.2

[Christos Tsantilas]

Hi Dave,
 can you please test the patch posted to squid-dev under the mail with 
title "[PATCH] Fix external_acl problems"



On 01/28/2016 05:38 PM, Dave Lewthwaite wrote:

Actually, scrub that - it does work in transparent/https mode - I had an issue 
with my logging when I was checking.

I’m assuming that dragging out the ALE in this way isn’t the safest way of 
getting it but it does seem to do the trick.

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Fix external_acl problems

[Christos Tsantilas]

Please ignore this thread it is duplicated mail.

On 01/28/2016 09:10 PM, Christos Tsantilas wrote:

Hi all,

After the patch r14351 created the following problems:
  - external_acl requires AccessLogEntry but ALE is not available
in many cases such as ssl_bump ACLs.
  - The %
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Hello and ssl_bump and External ACLs - 4.0.2

[Dave Lewthwaite]

Actually, scrub that - it does work in transparent/https mode - I had an issue 
with my logging when I was checking.

I’m assuming that dragging out the ALE in this way isn’t the safest way of 
getting it but it does seem to do the trick.
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] Build failed in Jenkins: trunk-full-matrix » clang,d-debian-unstable #94

[noc]

See 


--
[...truncated 6803 lines...]
Making dvi in helper
make[3]: Entering directory 
'
make[3]: Nothing to be done for 'dvi'.
make[3]: Leaving directory 
'
Making dvi in dns
make[3]: Entering directory 
'
make[3]: Nothing to be done for 'dvi'.
make[3]: Leaving directory 
'
Making dvi in ftp
make[3]: Entering directory 
'
make[3]: Nothing to be done for 'dvi'.
make[3]: Leaving directory 
'
Making dvi in parser
make[3]: Entering directory 
'
make[3]: Nothing to be done for 'dvi'.
make[3]: Leaving directory 
'
Making dvi in comm
make[3]: Entering directory 
'
make[3]: Nothing to be done for 'dvi'.
make[3]: Leaving directory 
'
Making dvi in eui
make[3]: Entering directory 
'
make[3]: Nothing to be done for 'dvi'.
make[3]: Leaving directory 
'
Making dvi in acl
make[3]: Entering directory 
'
make[3]: Nothing to be done for 'dvi'.
make[3]: Leaving directory 
'
Making dvi in format
make[3]: Entering directory 
'
make[3]: Nothing to be done for 'dvi'.
make[3]: Leaving directory 
'
Making dvi in clients
make[3]: Entering directory 
'
make[3]: Nothing to be done for 'dvi'.
make[3]: Leaving directory 
'
Making dvi in servers
make[3]: Entering directory 
'
make[3]: Nothing to be done for 'dvi'.
make[3]: Leaving directory 
'
Making dvi in fs
make[3]: Entering directory 
'
make[3]: Nothing to be done for 'dvi'.
make[3]: Leaving directory 
'
Making dvi in repl
make[3]: Entering directory 

[squid-dev] Planning for experiments with Digest, Link and metalink files.

[Eliezer Croitoru]

I have been working for some time on experimenting things related to 
metalinks files and I have couple things in my mind about it.
Now I am running for more then 4 month my local proxy service with 
SHA256 live digesting of all traffic using an eCAP module.
It's a small service and cannot take too much weight but it seems that 
with digest enabled or disabled squid doesn't loose enough speed that I 
seem to care.


Now I wanted to move into another side of my experiment and to implement 
some web service that uses the metalinks files data.
Since metalinks are for files or static objects the first thing is a 
simple file server.


I do not know what header to use for the digest hashes? I have seen that 
fedora mirror server uses "Digest: TYPE=hash" but from what I remember 
Henrik was talking about Content-MD5 and similar.
I can implement both Content-TYPE headers and Digest but what standards 
are the up-to-date?


Also the other question, how should the If-None-Match or another 
conditional should be used(since it was meant for ETAG)?


For now I am only working on a full hash match leaving aside any partial 
content pieces matching.


The options to validate file hash vs a static web service are:
- via some POST request(which can return a 304\302\200)
- via special if-none-match header

Also I had in my mind a situation that the client has couple hashes and 
want to verify a full match to the whole set or to at-least one from a 
set. What do you think should be done?


The current implementations relies on the fact that everybody uses the 
same default hash but I am almost sure that somewhere in the future 
people would like to run Digest match to some kind of salted algorithm 
so I am considering what would be the right way to allow\implement 
support for such cases.

Am I dreaming too much?

Another issue is a PUT requests, does it makes sense to attach some 
Digest or other headers by the user that will be stored with the file 
metadata or metalink file? compared.. to uploading two files one for the 
object and another one for the metalink file?


Thanks,
Eliezer
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] Jenkins build is back to normal : trunk-polygraph #941

[noc]

See 

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Planning for experiments with Digest, Link and metalink files.

[Amos Jeffries]

On 28/01/2016 9:18 p.m., Eliezer Croitoru wrote:
> I have been working for some time on experimenting things related to
> metalinks files and I have couple things in my mind about it.
> Now I am running for more then 4 month my local proxy service with
> SHA256 live digesting of all traffic using an eCAP module.
> It's a small service and cannot take too much weight but it seems that
> with digest enabled or disabled squid doesn't loose enough speed that I
> seem to care.
> 

The other one to test is AES hashing. IIRC, that should be faster than
SHA256 (but slower than MD5).


> Now I wanted to move into another side of my experiment and to implement
> some web service that uses the metalinks files data.
> Since metalinks are for files or static objects the first thing is a
> simple file server.
> 
> I do not know what header to use for the digest hashes? I have seen that
> fedora mirror server uses "Digest: TYPE=hash" but from what I remember
> Henrik was talking about Content-MD5 and similar.
> I can implement both Content-TYPE headers and Digest but what standards
> are the up-to-date?
> 

AFAIK, the header should be defined in the metalinks RFC document,
(whichever that is). Content-MD5 is related, but when I looked at its
specification it was locked to MD5 algorithm and not extensible to
better hashes.


> Also the other question, how should the If-None-Match or another
> conditional should be used(since it was meant for ETAG)?

The metalinks does not use conditional headers at all.
 defines either a GET
requet with Range headers or a HEAD request as the way to fetch the
Links and Digest header details.

The idea is to fetch the headers from each mirror and compare the Digest
value and/or ETag to ensure it is providing the right object.
Accumulating any new Links to the possible set as things progress. If
the Digest does not match those headers are probably "broken" and
another mirror needs to be tried.

Metalinks use-case is for resuming a broken fetch or splitting download
of a large object across multiple mirrors in an attempt to boost D/L
speed with parallelisation - but we dont like that second one because
Squid still lacks Range/partial caching of the resulting parts.


There is an "If:" header in WebDAV that seems to provide the necessary
semantics for passing the hashes in conditional requests. But the text
is not very clear on what field-value format to use, or how to interpret
the lists it contains.



> 
> For now I am only working on a full hash match leaving aside any partial
> content pieces matching.
> 
> The options to validate file hash vs a static web service are:
> - via some POST request(which can return a 304\302\200)
> - via special if-none-match header
> 
> Also I had in my mind a situation that the client has couple hashes and
> want to verify a full match to the whole set or to at-least one from a
> set. What do you think should be done?
> 
> The current implementations relies on the fact that everybody uses the
> same default hash but I am almost sure that somewhere in the future
> people would like to run Digest match to some kind of salted algorithm
> so I am considering what would be the right way to allow\implement
> support for such cases.
> Am I dreaming too much?
> 
> Another issue is a PUT requests, does it makes sense to attach some
> Digest or other headers by the user that will be stored with the file
> metadata or metalink file? compared.. to uploading two files one for the
> object and another one for the metalink file?

We want to eventually be storing the payload/body of the PUT, and
updating its URL / Store-ID entry to be based on the response
Content-Location header that comes back from the server.

In light of that, doing a hash of that body makes sense. The problem is
just that Squid does not currently implement that storage idea at all.
So there is nothing stored until a later GET pulls it back into the proxy.

HTH
Amos

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [PATCH] securiy_fake_certv ; aka helpers/ shuffling exemplar

[Alex Rousskov]

On 01/28/2016 06:55 AM, Amos Jeffries wrote:
> This patch demonstrates my proposed helpers/ shuffling by updating the
> demo certificate validator.
> 
> * creates src/security/certv/ for certificate validation helpers.
>  To distinguish from certificate generator helpers which would be in
> src/security/certg/.

Please consider using more than one letter to distinguish directories
(e.g., cert_gen and cert_validators).


> +(C) 2012 The Measurement Factory, Author: Tsantilas Christos

If it helps, you may use the standard Squid boilerplate for Factory
files and avoid a special CREDITS mention.


> + One fake helper that it does not actually perform any
> +certificate checks is provided for testing and example code for 
> writing
> +custom helpers.

s/that it does/that does/
s/and example code for/and as an example for/
s/custom helpers/real validators/


I did not audit the path but have no objections (with or without the
above polishing touches).


Thank you,

Alex.

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev