[Privoxy-devel] any interest in a faster way to check blacklists?

[Fabian Keil]

Lee <ler762 at gmail.com> wrote on 2022-10-03 at 12:45:38:

> On 10/2/22, Fabian Keil  wrote:
> > Lee  wrote on 2020-02-13 at 12:19:56:
> >
> > CC'ing Lee as Mailman unsubscribed gmail addresses a while
> > ago due to Google bouncing mails again ...
> 
> *sigh*  the msg sent from your .de address has a
> Why is this message in Spam? It's similar to messages that were
> detected by our spam filters.
> notice at the top even though it showed up in my inbox :\
> 
> I'm about ready to start paying for mail if they have a decent privacy
> policy.  Or switch to some other free mail w/ a tolerable privacy
> policy.  Anyone have any suggestions?

Unfortunately I'm not satisfied with the provider for my
main address either.

> > I still think a modified version of the commit would be nice to have
> > but as it's intended to be used by scripts I'm not sure why the generated
> > page has to be HTML.
> 
> Because my ignorance?  You get to the cgi page from http://p.p so the
> result is html?
> 
> I was going for easy and the current show-url-info function returns
> html so I copied that already working code and then tried to figure
> out how to make it faster.

We already have other CGI pages that aren't HTML, for example:
<https://p.p/wpad.dat>.

> > Returning plain text may be even faster although
> > I didn't benchmark it.
> 
> Possibly?  But I suspect returning text instead of text wrapped in
> html it isn't going to be that much of an improvement..  at least if
> what gets returned is small enough to fit into a single write from
> privoxy and a single read from the user program.
>   (i have a vague memory of seeing awk do multiple reads from privoxy
> to get all the returned info from show-url-info.  And Privoxy doing
> multiple reads to get the template into memory didn't help either..
> Shrinking what privoxy wrote down to what awk could read in a single
> IO request was a big improvement as was keeping the template in memory
> instead of reading it in from disk)
> 
> Then again, I was pushing what I thought I was capable of, so returning just
>   blocked yes/no
> instead of the whole 'Final results:' info would probably be faster.
> Maybe even consistently measurably faster :)  How much 'in-memory'
> work needs to be removed before noticing a consistent improvement?

I guess answering that question would need additional benchmarks.

> And _not_ checking to see if the action files have been modified makes
> a noticeable difference - ie. jcc.c

We could add a config file directive for this.

Do you still have the benchmark results for this?

> > I'm also not sure that it has to show up in the menu.
> 
> It doesn't, but why not?  In the menu makes it easier for the casual
> user to discover vs. having to look thru the source code to figure out
> that hidden goodies there are in the CGI functions.

The downside of adding stuff to the menu is that it makes
it harder to find the already existing entries.

Instead of adding it to the menu we could add a link to
the /show-url-info page with a description.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.privoxy.org/pipermail/privoxy-devel/attachments/20221004/425172fa/attachment.bin>