system.rootrc ships three settings that nothing reads (WebGui.HttpLoopback, WebGui.WaitForTmout, Browser.StartUrl) #23036

Summary

config/rootrc.in, which becomes the installed system.rootrc, ships three settings that no code reads. Setting them has no effect and nothing reports that.

One of the three, WebGui.HttpLoopback, is also documented in the class documentation of RWebWindowsManager and controls whether the web GUI's HTTP server binds to loopback only, so I think it is worth separating from the other two.

WebGui.HttpLoopback — documented in two places, read in neither

config/rootrc.in:243-244:

# Use only loopback address to bind http server (default - yes)
WebGui.HttpLoopback:        yes

and gui/webdisplay/src/RWebWindowsManager.cxx:362-365:

/// One also can bind HTTP server socket to loopback address,
/// In that case only connection from localhost will be available:
///
///      WebGui.HttpLoopback: yes

The value is never read. Loopback mode comes from a file-static variable instead:

gui/webdisplay/src/RWebWindowsManager.cxx:94    static bool gWebWinLoopbackMode = true;
gui/webdisplay/src/RWebWindowsManager.cxx:130       gWebWinLoopbackMode = on;      // SetLoopbackMode()
gui/webdisplay/src/RWebWindowsManager.cxx:153       return gWebWinLoopbackMode;    // IsLoopbackMode()
gui/webdisplay/src/RWebWindowsManager.cxx:513       bool assign_loopback = gWebWinLoopbackMode;

so the only way to change it is the C++ API RWebWindowsManager::SetLoopbackMode(), whose one caller in the tree is graf3d/eve7/src/REveManager.cxx:636.

What makes this look accidental rather than intended is line 513 itself. Every neighbouring setting in that same block is read from gEnv:

int http_wstmout = gEnv->GetValue("WebGui.HttpWSTmout", 10000);
int http_maxage  = gEnv->GetValue("WebGui.HttpMaxAge", -1);
fLaunchTmout     = gEnv->GetValue("WebGui.LaunchTmout", 30.);
fReconnectTmout  = gEnv->GetValue("WebGui.ReconnectTmout", 15.);
bool assign_loopback = gWebWinLoopbackMode;                              // <-- only one not from gEnv
const char *http_bind = gEnv->GetValue("WebGui.HttpBind", "");
bool use_secure = RWebWindowWSHandler::GetBoolEnv("WebGui.UseHttps", 0) == 1;
const char *ssl_cert = gEnv->GetValue("WebGui.ServerCert", "rootserver.pem");

The default is the safe one (gWebWinLoopbackMode = true), so this is not a case of ROOT listening more widely than expected out of the box. The effect is the opposite: someone who deliberately sets WebGui.HttpLoopback: no in system.rootrc, following the documentation, gets loopback binding anyway and no diagnostic. Since the setting is about network exposure, silently ignoring it in either direction seems worth fixing rather than leaving.

I do not want to guess which way you want it:

• if the setting is meant to work, assign_loopback could read RWebWindowWSHandler::GetBoolEnv("WebGui.HttpLoopback", 1) == 1 — matching how WebGui.UseHttps is read two lines below — while SetLoopbackMode() keeps overriding it;
• if the C++ API is deliberately the only control, then the rootrc.in entry and the four documentation lines should go.

WebGui.WaitForTmout and Browser.StartUrl — no reader anywhere

• WebGui.WaitForTmout (config/rootrc.in:253, described as "default timeout (in seconds) for synchronous actions like producing images on clients"). The string appears only on that line — nowhere else in the repository, in any file type.
• Browser.StartUrl (config/rootrc.in:220). The only other occurrence is gui/doc/v524/index.html:16, the v5.24 release notes. Its default also points at http://root.cern.ch/root/html/ClassIndex.html, on the retired root.cern.ch domain.

For these two I see no ambiguity — nothing reads them — so removing the entries looks right, but they are yours to keep if they are placeholders for something planned.

How this was found

I extracted every entry from config/rootrc.in and every GetValue("...") key from the source tree, then compared the two sets. 137 active entries, 335 distinct keys read.

The raw comparison gives many more hits than the three above, and I discarded the rest deliberately:

• TEnv resolves <system>.<hostname>.<program>.<resource>, so Unix.*.Editor is read as plain GetValue("Editor"). Entries with a * segment are matched on any trailing sub-path.
• Cocoa.EnableAntiAliasing and Cocoa.EnableFillAreaAntiAliasing are read from .mm sources, which a C++-only file filter misses.
• WebGui.OnetimeKey, WebGui.SingleConnMode and WebGui.UseHttps go through RWebWindowWSHandler::GetBoolEnv() rather than gEnv->GetValue() directly.
• WebGui.Chrome and WebGui.Edge are used as a prefix (RWebDisplayHandle.cxx:623, fEnvPrefix) with the suffix appended at runtime.

Only the three above survived all of that.

One limitation I should state: my clone is shallow, so I could not check when these entries stopped being read, or whether a reader existed at all. If that history matters I am happy to look again with a full clone.

I would be glad to open a PR for whichever resolution you prefer — including just the two removals, and leaving WebGui.HttpLoopback for someone who knows the intent.

ROOT version

master at fae567c0.

AI-assisted coding disclosure

AI-assisted (Claude Code), per the disclosure section in CONTRIBUTING.md. The comparison script and this report were produced with the tool, and I checked the result myself before filing: I read the CreateServer() block to see how the neighbouring settings are read, traced gWebWinLoopbackMode through its four uses and found its single external caller, searched the whole repository — every file type, not just C++ — for each of the three names, and worked through the false-positive classes listed above one at a time rather than reporting the script's raw output. I understand the finding and take responsibility for it.