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, 
security, ..?)

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?


Adam.