[squid-users] Introducing Charcoal - Centralised URL Filter for squid

Eliezer Croitoru eliezer at ngtech.co.il
Sat Jun 17 20:42:35 UTC 2017


Hey Nishant,

Responding to your idea and the whole concept of the helper and also comparing to GoLang binaries.

About the software design to run on-top of embedded hardware and a GoLang binary:
A GoLang helper can be compiled to almost any modern embedded device(else them mips based)
Also its more efficient then any software you will write with perl.
The only "limit" is CPU comparability and Binary size vs device free space.(in any case a perl helper would use more then a GoLang one).

The idea of writing a software that will implement concurrency in perl or python is nice and noble but I believe that probably
for small embedded devices you won't need a "robust" helper that supports concurrency or any other more complex solutions.

I believe that you should aim for the more standard hardware devices which squid can be built on-top such as:
- x86
- x86_64
- arm64
- arm5
- arm8

The above will benefit from a good and robust helper which supports concurrency.
Now that it's clear that your socket can handle more then only one request I will write a helper in GoLang that works with:
- concurrency
- better connection handling(being able to handle responses whenever they received)

I already wrote most of the code so I believe it's a matter of days for the helper to be ready.
Would I be able to receive some testing api key\token once the helper will be ready?

Thanks,
Eliezer

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: eliezer at ngtech.co.il


-----Original Message-----
From: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] On Behalf Of Nishant Sharma
Sent: Saturday, June 17, 2017 21:30
To: squid-users at lists.squid-cache.org
Subject: Re: [squid-users] Introducing Charcoal - Centralised URL Filter for squid



On 17 June 2017 11:17:38 PM IST, Amos Jeffries <squid3 at treenet.co.nz> wrote:

>That would mean making Squid aware of the internal workings of the 
>helper. Namely that it uses connections to a specific server, port and 
>which transport. One of the major points of flexibility with helpers is
>
>that this kind of thing is kept completely separate from Squid.

Re-reading my mail made me realise that it conveyed that helper architecture of squid be modified,  instead I wanted to say that we can modify the architecture of our helper, where it internally manages its own children which may speed-up the URL rewrite process.

>The URL-rewrite API being used by charcoal has the purpose of altering 
>the URI which Squid fetches content for a client from. Doing access 
>control through it instead of the access control API (external ACL 
>helper) is kind of borked from the start.

I agree, external ACL helper will also allow to have access to  additional information like user-agent, reply content-type etc. to have more granular control.

Regards,
Nishant
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users



More information about the squid-users mailing list