PHP and khttp

Posted by: cwillenbrock

PHP and khttp - 21/01/2002 13:15

I know this has been talked about before (I think I brought it up), but is it possible to get khttp working with PHP? I don't know much about khttp or Linux in general, but as I understand it..normally the webserver would be configured to hand off PHP file requests to the PHP installation, and would be parsed and returned to the web server for sending out to the client. Would this ever be possible on the empeg, using Hijack's khttp server?

I'd love to have an envrionment that supports PHP so I can do my own scripting.
Posted by: amit

Re: PHP and khttp - 21/01/2002 13:32

You might just want to use Apache on the Empeg. It can be configured/compiled to use pretty minimal resources (mainly a smaller memory footprint) so it shouldn't be too bad.

Regards
Amit
Posted by: cwillenbrock

Re: PHP and khttp - 21/01/2002 13:38

That would work, however I figured since I'm already running a web server with Hijack (and one that has a small enough footprint) it would be redundant to load a second. Also, I'm not nearly familiar enough with the Linux OS, let alone the empeg "version" of it to compile or install this myself without idiot-proof, step-by-step instructions.
Posted by: amit

Re: PHP and khttp - 21/01/2002 14:00

Do take into account that a web server "built-in" into the kernel would typically serve static content, and should not deal with executable/dynamic content. I haven't looked at the khttpd source for the Hijack kernel, so I am not sure (I believe somebody will correct me if I'm wrong :-)), but you cannot serve non-static content with it.

Interestingly enough, the most recent khttpd implementatoin in the Linux kernel actually passes all requests for non-static information to a regular user space web server.

Regards
Amit
Posted by: tonyc

Re: PHP and khttp - 21/01/2002 14:15

Oh my goodness, no. I believe it would be a very bad idea to have an HTTP daemon that runs in kernel space serving PHP, CGI, or whatever else. I don't want some malformed PHP script causing a kernel panic on my Empeg. There are just too many security concerns, as well as problems with memory usage, to allow for PHP from a kernel HTTP daemon.
Posted by: cwillenbrock

Re: PHP and khttp - 21/01/2002 14:20

Ok, so..the short answer to my question is..no.

Thanks.
Posted by: amit

Re: PHP and khttp - 21/01/2002 14:24

Yes, no to khttpd doing PHP. If you really want PHP, I will probably post instructions on doing a minimal Apache when my Empeg is up again.

Regards
Amit
Posted by: cwillenbrock

Re: PHP and khttp - 21/01/2002 14:26

That would be lovely.
Posted by: mlord

Re: PHP and khttp - 21/01/2002 18:26

Just install a real full-service httpd, and then disable khttpd using this in config.ini:

[hijack]
khttpd_port=0


Then you can script to your heart's content.

-ml
Posted by: eternalsun

Re: PHP and khttp - 23/01/2002 18:46

If you want a mother of a hack, then you can write a file system that masquerades PHP. That way, you can use the built in hijack web server, and it will be fooled into serving out dynamic content masquerading as static files on this invented file system.

Of course, it would work equally well with FTP.

Of course, it doesn't have to be PHP, it can be anything.

Calvin
Posted by: cwillenbrock

Re: PHP and khttp - 23/01/2002 20:04

You're making my brain hurt.
Posted by: amit

Re: PHP and khttp - 23/01/2002 21:55

IMHO a relatively cleaner hack (from a software engineering point of view, and also security-wise) is to have an in-kernel web server serving static content, and to have configuration file(s) in /proc that can tell this kernel server to pass requests for dynamic data to a user-space daemon.

For example, khttpd can run on port 80, and a PHP (or whatever else) enabled web server, say Apache, on port 8080. We tell khttpd to pass on cgi-bin and PHP related requests to Apache. Indeed, the latest khttpd in the Linux kernel works this way.

Regards
Amit
Posted by: mlord

Re: PHP and khttp - 24/01/2002 07:36

For strict security, it's gotta be best to have a userland web server handling ALL content. Placing static handling into the kernel adds risk, but can speed things up considerably.

Some background for late-joiners:

The Hijack khttpd is not at all related to the standard Linux khttpd, and serves a different purpose and audience (Empeg owners!). One major difference is that Hijack can provide directory listings, whereas the standard one passes such requests on to userland.

Cheers