httpd: Failure to start if -c and -h used together?

[xparq]

I may be doing something wrong, but

busybox-w64u-PRE-5296-g58627310e.exe httpd -c bb-web/cfg/httpd.conf 

and

busybox-w64u-PRE-5296-g58627310e.exe httpd -h bb-web/www

both start OK, but

busybox-w64u-PRE-5296-g58627310e.exe httpd -c bb-web/cfg/httpd.conf -h bb-web/www

Doesn't.

I'm not sure if there's a log somewhere, but no error is printed. The server process just doesn't show up in Task Manager (Win10/64).

BTW, the config file is this one line, just to have sex with the new CGI script interpreter feature:

*.php:C:/sz/SW/devel/tool/lang/PHP/php-cgi.exe

[rmyorston]

I think you either need to use an absolute path for the config file or put it in refer to it relative to the web directory.

(Task Manager? What's wrong with ps?)

[xparq]

I think you either need to use an absolute path for the config file or put it in refer to it relative to the web directory.

• Abs. paths are hopefully not required for this, and they indeed don't appear to be: both options work fine separately with rel. paths.

• The config path and the "home" path should be treated independent from each other, because they (mostly) are. If that "home" dir wasn't just a sad misnomer (from upstream) with the actual meaning of "web root", but had they meant something like "installation root" (closer to the usual meaning of a "home" dir), then there could be a valid case for coupling the -c and -h paths by assuming some default fs layout, when using relative paths. But -h is not that, it's just the web root.

• Also (as --help kinda also suggests), the natural option "precedence" is -c -h, as the web root could be specified in the config (at least in theory), so -c should depend on -h even less. \ \ Just looked up: seems to be a thing IRL. Good. Also, they do seem to call the -h path "server root" in the config... :)

  • Oh no, I may be wrong: I was looking at OpenWRT's httpd by accident. So I'm still unsure.

• Also, having the config -- god forbid -- inside the web root (-h dir) is something I would be to prude to consider... (even though that's exactly the impression one might get from the --help output).

• Nevertheless, I still tried some permutations trying to guess an assumed config dir location (if any) relative to the web dir, but had no luck. (Sorry, no records of those (pretty quick & random) attempts.)

I'll keep trying a little more then. :) But I think the case in the initial comment should still work regardless.

---

(Task Manager? What's wrong with ps?)

(Hehe, it's just that I'm mostly on Windows, and the super convenient Ctrl+Shift+Esc is already bound to TaskMan by default (and is in my muscle memory). Poor little ps would need some extra love & effort from daddy to be run. Also, TaskMan just keeps refreshing, once started, so a proper alternative would be top in a separate window, which is even less competitive with that Ctrl+Shift+Esc. BTW, the reason I mentioned it by name was just to preemptively answer the potential question "What do you mean doesn't start?" :) )

[xparq]

Oh, OK, I've found a mental model to salvage the situation: -h has a secret double life, meaning both the web root, and also some abstract "installation root", where the config file is supposed to be, and then the config is supposed to override -h to actually set the real web root!...

Haven't tested it yet, but I wager it'll work. It's weird though, all that should be trivially achievable just by the cmdline options alone, which are (supposedly) perfectly well equipped for that already.

[rmyorston]

The intent seems to be that there should be a main configuration file and, optionally, configuration files in each directory being served. The per-directory configuration files restrict what can be set: they don't affect the web root, for example, but they allow per-directory passwords to be set up.

When the server starts it initially sets home_httpd to the current working directory. This will be an absolute path. If the -h option is provided it will override that default setting and, per the comment mentioned elsewhere, if it's a relative path it will remain so.

The server then does chdir(home_httpd) and tries to read the main config file.

• If there's no -c option it uses /etc/httpd.conf.
• If the -c option has been given it'll use whatever path has been provided.
  • If it's an absolute path it uses that.
  • If it's a relative path it'll be relative to the web root. Since this being treated as the main configuration file it will allow home_httpd to be changed and perform chdir(home_httpd) to change the current directory. Normally a per-directory config file isn't allowed to do that.

When the server is forked to handle a request it remains in the web root directory and tries to read a config file from the directory containing the file to be served.

Of course, it's also possible that the Windows implementation gets some of this wrong.

[xparq]

Thanks a lot for the insider details, Ron! This can be closed as "not planned" then, I suppose.

The question mentioned in that "comment elsewhere" is still up though, so if you happen to know, still interested why relative -h paths are not normalized. E.g. is there a use case where the -h path may get appended to some other (rooter) root explicitly in the busybox code?

[rmyorston]

If you're satisfied the code is working as intended (leaving aside whether it's sensible for it to work like that) then this issue can be closed.

The other question requires further investigation. If/when I have anything to report I'll do that on issue #266.