> On Thursday 29 August 2002 14:59, Charles Steinkuehler wrote: > > I can commit to any updates/modifications to sh-httpd that may be > > required. I think it's possible to dramatically increase the CGI > > response of the existing sh-httpd when running CGI's, which would be > > a big help for a CGI driven admin interface. > > Great! I had JamesSturdevant send me his patched sh-httpd binary > since several of us had major problems applying the diff he had > posted. I can send it to you off-list. I haven't dug through it or done > a diff myself, but the POST function does work per my testing.
Please send me a copy... > The thttpd and uncgi combination is great, however uncgi has > not worked with sh-httpd in my testing due to CGI path restrictions. > Uncgi uses /cgi-bin/uncgi/'cgi-script' to interpret a CGI file and > sh-httpd does not support the "/path/binary/option" format. Exactly > what kind of "su wrapper" are you using to overwrite existing > configuration files or are you running thttpd as 'root'? I'm not familiar with "uncgi", but sh-httpd *SHOULD* support options passed after the CGI program name, as long as your SCRIPT_ALIAS variable in sh-httpd.conf is set properly. The extra path info is exported as the PATH_INFO environment variable...is this supposed to work some other way? > ************************* > *New thoughts* > > *To ease compatibility of many packages needing specific duplicate > information/variables, a break-up of certain conf files should be made > and a check for depending packages should be made within the web > module. The other option is building a new LEAF version that fits this > format (successor to Dachstein???). Internal network and DMZ information > would be excellent examples of possible problems. Modifying the existing > package database would not be a good option, unless we are going through > them anyway and following something along the lines of David D's Port > system. > > *The CGI scripts should only setup the environment and call executables. > If the actual executable is not integrated in CGI, a CLI configuration > script could use the same code and minimize the total codebase that > would need to be written. There are several of us that have already > written configuration code for existing LEAF variants, possibly some of > this code may be portable. I like this idea in general. The config system should make it easy to put a text, web, or whatever front end on the actual configuration utilities. Then, we could replace most of the existing lrcfg menu with something a bit more user friendly. I personally don't mind if existing packages need to be modified or extended for full/best compatability with the new auto-config system, but the new system should do something reasonable by default with existing packages (ie allow you to view/edit files that would show up in the lrcfg menu trees). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
