Dinesh Nair wrote:
> On Thu, 20 May 2004, Adam Nellemann wrote:
>>OK, I wasn't aware that mini_httpd didn't serve anything but index.php?
>>If that is truly the case, and that it would furthermore require
>>modification of binaries to change that behaviour, I certainly wouldn't
>>suggest that it be done for this reason.
> the special instance of mini_httpd which handles all captive portal
> accesses before it is allowed does this.
> the regular instance of mini_httpd which handles the webGUI operates as
> normal. thus if you've got captiveportal enabled, you'd see two instances
> of mini_httpd running.
OK, so the webGUI instance of mini_httpd IS allowed to serve more than
one file (index.php, exec.php, status.php etc.) then?
I'm not sure if there is much reason to take this thread any further?
My main point was that IF there was a need, among some users, to serve
files from m0n0wall, it shouldn't be very difficult, according to my
limited knowledge of how m0n0wall works, to make this possible without
impacting anything important (image size, used components, overhead,
It should (if I'm not overlooking something) be a matter of allowing
some (GUI?) instance of mini_httpd to serve files from a directory (in
RAM), and extending the function that copies files to RAM at boot time
to include this directory, and (optionally) make some kind of GUI for
controlling this feature (ie. an upload button and perhaps some kind
of access control settings).
But if there is much opposition (and not many proponents), I see no
reason to discuss this further. Even if I don't understand why people
are so opposed to the concept?