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

[Lee]

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.

> 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

> Again the name could probably be improved if we think about
> it some more.

Sure.  I'm pretty horrible at naming

Regards
Lee