On Mon, 2005-07-18 at 15:57 -0400, Evert | Rooftop wrote: > Fredrik Tolf wrote: > >I've begun to be more and more displeased with Apache lately, so I've > >been thinking of writing my own HTTP server instead. I still want PHP > >support, but writing a new SAPI for PHP seems like overkill. > > > >Therefore, is it possible to use PHP from the command line, but still > >enable some HTTP-server-only stuff, like GET and POST variables, > >cookies, session management, file uploads, and so on? I haven't been > >able to find any docs on doing that, but I'm thinking that it should be > >possible. > > > >So, can someone either point me to some docs in this, or, lacking such, > >give me a short intro to it? > > > Hi Fredrick, Hi! > I wonder too why you are displeased with apache =) to me (and I know > many others in this group) it is the best webserver around. One of the problems for me with Apache is that it's too complex. To begin with, it contains a million feature that I'll never use, but which does bring up resource consumption. It also contains a lot of high-performance stuff which impedes flexibility, such as not being able to keep file descriptors to instead be able to load-balance requests between workers and servers. Almost foremost, however, I'm looking to build a server with far better support for multi-user operation. While Apache with UserDir and suexec does some things good, it cannot, for example, running PHP applications as different users. I know there is a worker module for apache that can run different vhosts as different users, but that's just vhosts -- you still cannot define arbitrary authoritative domains (such as directories) that are run as different users. At least not the way I've understood it. I'm just running a multi-user POSIX system at home with shell access, and having to run all web processing as the apache user, well, kinda sucks, when it could instead actually be run as the user it should run as, and access the users' data correctly. > If you would want to do it (and not use php as a library [SAPI-style] ) > you shouldn't look in to CLI, but into CGI. Yes, that's what I meant. I meant calling PHP's CLI interface with a CGI-style interface. > Using CGI you can lauch a php process every time a script is called. > Many years ago they discovered this isn't the best way to handle this. > To launch a process every time a script is called takes too much time > and resources. > So they invented the FASTCGI interface, which allows php processes to > remain persistant in the memory. You would probably (depending on your > demands) want to have a bunch of php processes forked in the memory. While that is true, I don't think that the "real" CGI interface would be a problem with the kind of load that my server is under. > If it's an experment, I would say go for it. If you want to use it > commercially or at least in a live enviroment I would strongly > discourage you to do it. Well, of course it's not a commercial environment. I just want a good multi-user server on my home system. > In any case, if you want it to be fast, you want to do it 'SAPI-style'.. Well, I've been considering writing a SAPI for PHP. I haven't actually looked at the SAPI interface, but I'm getting the feeling that that's probably more work than writing an entire web server. ;) Anyways, thanks for your input! Fredrik Tolf -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
