[Privoxy-devel] 0008-speed-up-processing-of-cgi_show_url_final_info

[Fabian Keil]

Lee <ler762 at protonmail.com> wrote on 2023-08-25 at 03:22:01:

> On Thursday, August 17th, 2023 at 7:42 AM, Fabian Keil wrote:
> 
> > Again I think that you have a valid use case but would
> > prefer another solution.
> > 
> > I think experienced users are used to requesting https://p.p/
> > after configuration changes to trigger a configuration reload
> > and if I interpret your patch correctly it would break this
> > use case.
> 
> It looks like not quite..
> $ touch user.action
> $ touch user.filter
> $ curl -q -sS --proxy 127.0.0.1:8118 --referer
> http://config.privoxy.org/ http://config.privoxy.org/show-status >
> /dev/null
> 
> and this shows up in the log:
> 2023-08-24 22:50:51.213 00001410 Info: Loading filter file: .\user.filter
> 2023-08-24 22:50:51.228 00001410 Info: Loading actions file:
> .\user.action 2023-08-24 22:50:51.249 00000e10 Request:
> config.privoxy.org/show-status 2023-08-24 22:50:51.257 00000e10 Crunch:
> CGI Call: http://config.privoxy.org/show-status
> 
> My _guess_ is that an initial request will trigger the
> any_loaded_file_changed check; it's only when the user is continuing to
> talk on a previously opened socket _and_ is requesting a cgi function
> that the any_loaded_file_changed function is skipped.  ... which is
> exactly my situation - the program opens a connection to privoxy and
> loops on (give a host name to the show-url-info function, read the
> result) All that on the one connection because the windows/cygwin
> startup time is **slow**, firing up a new connection for each host name
> takes ages.
> 
> In any case, requesting http://p.p triggering a configuration change
> check is a side affect.  One could accomplish the same thing requesting
> www.example.com or any other non-cgi url, but I'd suggest that if a user
> wants to make sure config files are current it would be better to make a
> cgi function that does the "reload any config, user or action file
> updated" function instead of having it be a side-affect of something
> else.

I think it's safe to assume that by now lots of users are used to
being able to trigger configuration checks and reloads by requesting
http(s)://p.p/ so we can't simply change this behaviour without
annoying lots of users.

> > Adding support for a "check-for-configuration-changes" variable
> > to the CGI handlers you care about seems cleaner to me and should
> > not affect users that don't set the variable.
> 
> Doesn't adding a new cgi function to make sure all files are updated
> seem better?  No extra variables and no depending on side affects

It would still inconvenience users that are used to the current behaviour.

However I think another option would be to add a config directive named
something like skip-automatic-configuration-checks to suppress the current
checks completely. Users that enable the directive would have to restart
Privoxy to reload the configuration or send a SIGHUP signal or "we" could
then add a CGI function like you proposed that causes the reload.

> > Again the name could probably be improved if we think about
> > it some more.
> 
> Sure.  I'm pretty horrible at naming

I was referring to the name I proposed.

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/20230830/4a68b599/attachment.bin>