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

[Lee]

On Wednesday, August 30th, 2023 at 1:39 PM, Fabian Keil wrote:

> Lee 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.

To be clear, what changes is *re-loading* http(s)://p.p/ in a browser.  The initial request always (at least in my testing) triggers a
  Info: Loading <whatever changed> file: 
It's only when one visits http://config.privoxy.org/show-url-info, changes one or more config / action or filter files and (in firefox) clicks on the 'Reload current page (CTRL+R)' button that updated files are not re-loaded.  Which is easily fixed.. hold down the shift key and click on the 'Reload current page (CTRL+R)' button and whatever files were updated get re-loaded.

> > > 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.

Please don't do that.  Or at least, not on my account.. I'd rather not make any changes to Privoxy than require a restart or SIGHUP to get updated files read in.

I'm still using my 'Crunch: Blanked: xxx' log patch from however long ago - eg.
  2023-08-30 15:40:31.043 000024a0 Crunch: Blanked: location.services.mozilla.com:443
I don't mind continuing to apply my
  if (continue_chatting && !(csp->flags & CSP_FLAG_CRUNCHED) && ...
patch in jcc.c for my own version of privoxy.

Thanks
Lee