# RFC: built-in web server in CLI. - Thread: https://externals.io/message/51546 - Original archive: https://news-web.php.net/php.internals/51546 - Started by Moriyoshi Koizumi on 2011-03-02T20:55:42+00:00 - Messages: 29 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/51546.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #51546 — Moriyoshi Koizumi — 2011-03-02T20:55:42+00:00 URL: https://externals.io/message/51546#51546 Hi, Just to let you know that I wrote a RFC about built-in web server feature with which PHP can serve contents without a help of web servers. That would be handy for development purpose. If interested, have a look at http://wiki.php.net/rfc/builtinwebserver . Regards, Moriyoshi --- ## #51547 — Rasmus Lerdorf — 2011-03-02T20:59:26+00:00 URL: https://externals.io/message/51546#51547 · In reply to: #51546 > Hi, > > Just to let you know that I wrote a RFC about built-in web server > feature with which PHP can serve contents without a help of web > servers. That would be handy for development purpose. > > If interested, have a look at http://wiki.php.net/rfc/builtinwebserver . I like it. Need to go through it very carefully and look for security-related issues though. Make sure all memory handling is safe. -Rasmus --- ## #51548 — Pierre Joye — 2011-03-02T22:38:01+00:00 URL: https://externals.io/message/51546#51548 · In reply to: #51547 > > > […] > > I like it. Need to go through it very carefully and look for > security-related issues though. Make sure all memory handling is safe. Same here, very handy. I would not worry too much about security related issues as such builtin server should really be used for development purposes only (yes, users do bad things even if we say to do not it :). -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #51549 — keisial@gmail.com — 2011-03-02T23:05:26+00:00 URL: https://externals.io/message/51546#51549 · In reply to: #51546 Moriyoshi Koizumi wrote: > Hi, > > Just to let you know that I wrote a RFC about built-in web server > feature with which PHP can serve contents without a help of web > servers. That would be handy for development purpose. > > If interested, have a look at http://wiki.php.net/rfc/builtinwebserver . > > Regards, > Moriyoshi I like the idea. Regarding the patch (https://gist.github.com/835698): I don't see a switch to disable the internal parse on configure. I'd expect the files to be on its own folder inside sapi, even being able to bundle them in a single binary. Why is this needed on WIndows? + ADD_FLAG("LIBS_CLI", "ws2_32.lib"); Surely php will already link with the sockets library for its own functions. The http parser code seems copied from https://github.com/ry/http-parser and it may not be a good idea to modify it downstream, but it seems to do more things than strictly needed by php (eg. there are more methods than those a php server would take use). It also seems to be a hand-coded lexer, so that's much more verbose than a set of rules. The patch looks messy as it splits main in two functions, so it gets hard to follow, but is probably good overall. The change from php_printf to printf in line 3988 looks wrong. Any special reason to disable it on PHP_CLI_WIN32_NO_CONSOLE ? --- ## #51552 — Moriyoshi Koizumi — 2011-03-03T03:47:24+00:00 URL: https://externals.io/message/51546#51552 · In reply to: #51549 2011/3/3 Ángel González : > Moriyoshi Koizumi wrote: > > […] > I like the idea. > > Regarding the patch (https://gist.github.com/835698): > I don't see a switch to disable the internal parse on configure. I don't see any obvious reason it should be able to be turned off through the build option. The only problem is binary size increase, which I guess is quite subtle. > I'd expect the files to be on its own folder inside sapi, even being > able to > bundle them in a single binary. > > Why is this needed on WIndows? > > + ADD_FLAG("LIBS_CLI", "ws2_32.lib"); > > Surely php will already link with the sockets library for its own functions. Of course the objects that directly involves generation of php.exe depend on WinSock functions. Other socket related portion is inside php5.dll (php5ts.dll) whose imported symbols cannot be referred to unlike ELF shared objects. > The http parser code seems copied from https://github.com/ry/http-parser and > it may not be a good idea to modify it downstream, but it  seems to do more > things than strictly needed by php (eg. there are more methods than those a > php server would take use). > It also seems to be a hand-coded lexer, so that's much more verbose than a > set of rules. Do we really have to look into the parser right now? I don't think we have to limit the methods that the server can accept since there is no reason limiting it though the server can deal with, I don't find it a problem for it to be hand-coded either. > The patch looks messy as it splits main in two functions, so it gets > hard to follow, > but is probably good overall. Assuming you are mentioning about the option parsing portion of the code, yes, it's a bit messy, but I had to do so because runtime initialization procedure is very different from the ordinary CLI. > The change from php_printf to printf in line 3988 looks wrong. php_printf() eventually redirects the output to sapi_module.ub_write(), which should only be available after proper SAPI initialization. The changed part can be reached before the initialization and it absolutely makes no sense to use php_printf() when you simply want to print a message text before the script starts in the console. > Any special reason to disable it on PHP_CLI_WIN32_NO_CONSOLE ? cli-win32 version of PHP doesn't have an associated console and is supposed to use to create applications without console interactions (i.e. GUI). So, It doesn't make sense to enable this feature for it. Regards, Moriyoshi --- ## #51553 — Alexey Zakhlestin — 2011-03-03T06:35:16+00:00 URL: https://externals.io/message/51546#51553 · In reply to: #51546 > Hi, > > Just to let you know that I wrote a RFC about built-in web server > feature with which PHP can serve contents without a help of web > servers.  That would be handy for development purpose. > > If interested, have a look at http://wiki.php.net/rfc/builtinwebserver . Interesting, indeed. I noticed, that you hardcode mimetypes and index_files. Mimetypes can probably be obtained from the system — we even had some extension doing that. And index_files should be configurable, because there are some situations when people don't want any mime-types at all. Also, it would be good to be able to configure which files are actually parsed by php, not just served. Currently, these are only ".php" files -- Alexey Zakhlestin, http://twitter.com/jimi_dini http://www.milkfarmsoft.com/ --- ## #51556 — keisial@gmail.com — 2011-03-03T09:16:41+00:00 URL: https://externals.io/message/51546#51556 · In reply to: #51552 Moriyoshi Koizumi wrote: > > […] > I don't see any obvious reason it should be able to be turned off > through the build option. The only problem is binary size increase, > which I guess is quite subtle. Seems sufficiently different from normal cli. > > […] > Assuming you are mentioning about the option parsing portion of the > code, yes, it's a bit messy, but I had to do so because runtime > initialization procedure is very different from the ordinary CLI. Wasn't critizising you. It's a limitation of unified diffs, which can't say "move this bunch of code 25 lines down". A bit hard to follow, but aparently good. > > […] > php_printf() eventually redirects the output to > sapi_module.ub_write(), which should only be available after proper > SAPI initialization. The changed part can be reached before the > initialization and it absolutely makes no sense to use php_printf() > when you simply want to print a message text before the script starts > in the console. Fair enough. > > […] > cli-win32 version of PHP doesn't have an associated console and is > supposed to use to create applications without console interactions > (i.e. GUI). So, It doesn't make sense to enable this feature for it. With the embedded web server, the interaction would be done via the browser. --- ## #51557 — Moriyoshi Koizumi — 2011-03-03T09:33:50+00:00 URL: https://externals.io/message/51546#51557 · In reply to: #51553 Hi, > > > […] > > Interesting, indeed. > > I noticed, that you hardcode mimetypes and index_files. > Mimetypes can probably be obtained from the system — we even had some > extension doing that. > And index_files should be configurable, because there are some > situations when people don't want any mime-types at all. > > Also, it would be good to be able to configure which files are > actually parsed by php, not just served. Currently, these are only > ".php" files > We coundn't always count on the existence of mime.types, which is likely installed with Apache that is uncalled for. Neither do I see any good reason to make index files configurable because I have hardly seen such a peculiar setting for several years that uses file names other than index.html or index.php for index files. I used to use index.htm for technical reasons though. In short, if you need to configure it more, it'd be better off installing Apache to do the right job. I would like to cover just a marginal part of the developer needs with this. Regards, Moriyoshi > -- > Alexey Zakhlestin, http://twitter.com/jimi_dini > http://www.milkfarmsoft.com/ --- ## #51558 — Moriyoshi Koizumi — 2011-03-03T09:44:46+00:00 URL: https://externals.io/message/51546#51558 · In reply to: #51556 Hi, 2011/3/3 Ángel González : > Moriyoshi Koizumi wrote: > > […] > Seems sufficiently different from normal cli. I've seen a number of people arguing on the same, but I'd rather have them both in for the sake of simplicity. As discussed when the CLI version of PHP was born, multiple PHP binaries actually have confused the users to a certain degree. > > […] > Wasn't critizising you. It's a limitation of unified diffs, which can't say > "move this bunch of code 25 lines down". A bit hard to follow, but > aparently good. I would have put a whitespace-ignoring diff as well ;-) > > […] > With the embedded web server, the interaction would be done via the browser. It is not intended to be daemonized at all since it's just a development web server. To do more, Apache should work great then. Regards, Moriyoshi --- ## #51559 — Derick Rethans — 2011-03-03T12:09:10+00:00 URL: https://externals.io/message/51546#51559 · In reply to: #51557 > In short, if you need to configure it more, it'd be better off > installing Apache to do the right job. I would like to cover just a > marginal part of the developer needs with this. I like it being small and simple as well. Sometimes "forcing" people to use one method actually makes things easier to use. cheers, Derick --- ## #51560 — Lester Caine — 2011-03-03T12:46:29+00:00 URL: https://externals.io/message/51546#51560 · In reply to: #51559 Derick Rethans wrote: > > […] > I like it being small and simple as well. Sometimes "forcing" people to > use one method actually makes things easier to use. AND a lot easier to debug when people are having problems getting something working ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #51566 — Christopher Jones — 2011-03-04T02:17:09+00:00 URL: https://externals.io/message/51546#51566 · In reply to: #51546 > Hi, > > Just to let you know that I wrote a RFC about built-in web server > feature with which PHP can serve contents without a help of web > servers. That would be handy for development purpose. > > If interested, have a look at http://wiki.php.net/rfc/builtinwebserver . > > Regards, > Moriyoshi > To allow for future changes, all options should require flags. For example, php -S localhost:8000 -d docroot instead of the currently proposed php -S localhost:8000 docroot Have you thought about integration with run-tests.php? -- Email: christopher.jones@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ --- ## #51567 — Moriyoshi Koizumi — 2011-03-04T06:40:45+00:00 URL: https://externals.io/message/51546#51567 · In reply to: #51566 On Fri, Mar 4, 2011 at 11:17 AM, Christopher Jones wrote: > > > > > […] > > To allow for future changes, all options should require flags. > For example, php -S localhost:8000 -d docroot instead of the > currently proposed php -S localhost:8000 docroot That might make sense. I am thinking that being unable to specify a document root with a router script is a bit inconsistent. > Have you thought about integration with run-tests.php? Not in mind yet, but if it's better than CGI. Moriyoshi > -- > Email: christopher.jones@oracle.com > Tel:  +1 650 506 8630 > Blog:  http://blogs.oracle.com/opal/ --- ## #51920 — Philip Olson — 2011-04-16T23:17:43+00:00 URL: https://externals.io/message/51546#51920 · In reply to: #51567 Greetings Moriyoshi and all, Are people still thinking about this? And how about applying the current/revised patch to trunk thus making it easier to play with and break, but not freeze its features/API yet. Also the wiki is up again so: - RFC: https://wiki.php.net/rfc/builtinwebserver - Patch is here: http://gist.github.com/835698 Regards, Philip --- ## #51921 — Mikael Fernandus S — 2011-04-17T14:51:15+00:00 URL: https://externals.io/message/51546#51921 · In reply to: #51920 As a non core dev, I would like to say that the patches are so handy and this feature will be so helpful in portable php development scenarios. +1 on this and hoping it will make into the main branch pretty soon. Similar with others, my suggestion is to put the docroot and router script as parts of the options. An option to specify max number of connections would be nice but perhaps it can be in a future wishlist. Regards, Mike > Greetings Moriyoshi and all, > > Are people still thinking about this? And how about applying the current/revised patch to trunk thus making it easier to play with and break, but not freeze its features/API yet. > > Also the wiki is up again so: > >  - RFC: https://wiki.php.net/rfc/builtinwebserver >  - Patch is here: http://gist.github.com/835698 > > Regards, > Philip --- ## #51922 — Richard Quadling — 2011-04-17T20:29:15+00:00 URL: https://externals.io/message/51546#51922 · In reply to: #51921 > As a non core dev, I would like to say that the patches are so handy > and this feature will be so helpful in portable php development > scenarios. > +1 on this and hoping it will make into the main branch pretty soon. > > Similar with others, my suggestion is to put the docroot and router > script as parts of the options. An option to specify max number of > connections would be nice but perhaps it can be in a future wishlist. > > Regards, > Mike > > > > […] What would happen if you could combine these patches with the Win32Service pecl extension ... could you not have a real PHP orientated web server running which was capable of starting up and shutting down with the OS. Hey! Who would need IIS or Apache then! (OK. Just kidding). -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY --- ## #51924 — Andi Gutmans — 2011-04-18T04:07:00+00:00 URL: https://externals.io/message/51546#51924 · In reply to: #51922 I really like the idea. Just to be clear though I'd change: Server is listening on localhost:8000... Press CTRL-C to quit. To something like: PHP Development Server is listening on localhost:8000... Press CTRL-C to quit. I think that makes it very clear this is for development and enhancements will be focused on ensuring the dev environment works and not trying to make this into a mini Apache. Andi > -----Original Message----- > From: Richard Quadling [mailto:rquadling@gmail.com] > Sent: Sunday, April 17, 2011 1:29 PM > To: Mikael Fernandus S > Cc: Philip Olson; Moriyoshi Koizumi; Christopher Jones; internals Mailing List > Subject: Re: [PHP-DEV] RFC: built-in web server in CLI. > > > > […] > current/revised patch to trunk thus making it easier to play with and break, but > not freeze its features/API yet. > > […] > > > What would happen if you could combine these patches with the Win32Service > pecl extension ... could you not have a real PHP orientated web server running > which was capable of starting up and shutting down with the OS. > > Hey! Who would need IIS or Apache then! (OK. Just kidding). > > -- > Richard Quadling > Twitter : EE : Zend > @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY > > -- > To unsubscribe, visit: > http://www.php.net/unsub.php --- ## #51938 — Michael Wallner — 2011-04-19T12:17:37+00:00 URL: https://externals.io/message/51546#51938 · In reply to: #51920 > Greetings Moriyoshi and all, > > Are people still thinking about this? And how about applying the > current/revised patch to trunk thus making it easier to play with and > break, but not freeze its features/API yet. > > Also the wiki is up again so: > > - RFC: https://wiki.php.net/rfc/builtinwebserver > - Patch is here: http://gist.github.com/835698 The php_http_* "namespace" is actually already used by pecl_http? Regards, Mike --- ## #51939 — Michael Morris — 2011-04-19T14:35:40+00:00 URL: https://externals.io/message/51546#51939 · In reply to: #51938 Since the goal of this is debugging might I suggest borrowing a statement from the Adobe Flash environment: trace. Trace sends output to the debug console. If given a variable it would format it as print_r currently does. When encountered by PHP in other modes it would be silently ignored. Thoughts? > > > > […] > > The php_http_* "namespace" is actually already used by pecl_http? > > Regards, > Mike --- ## #51940 — Michael Morris — 2011-04-19T14:44:50+00:00 URL: https://externals.io/message/51546#51940 · In reply to: #51939 Pardon me for following up my own post, but there is room for a range of functions here other than trace that could send their output to the command line where the server was started. watch ($var) -> $var is sent to the console on the line this statement is made with the statment "now watching 'var'.. init value "x", and then each time it changes it is updated in the console. traceStack() -> as trace, but the current stack is reported. traceAll() Return all variables in local scope and the current stack. stop() Halt execution as die or exit, unlike them it's arguments are sent to console instead of browser. On Tue, Apr 19, 2011 at 10:35 AM, Michael Morris wrote: > Since the goal of this is debugging might I suggest borrowing a statement > from the Adobe Flash environment: trace. > > Trace sends output to the debug console. If given a variable it would > format it as print_r currently does. When encountered by PHP in other modes > it would be silently ignored. > > Thoughts? > > > > > […] --- ## #51941 — David Muir — 2011-04-20T02:29:14+00:00 URL: https://externals.io/message/51546#51941 · In reply to: #51940 I'm not sure if this is needed when there are already solutions for this. eg, syslog, error_log, or other userland solutions like Zend_Log, sfLogger, etc. Cheers, David > Pardon me for following up my own post, but there is room for a range of > functions here other than trace that could send their output to the command > line where the server was started. > > watch ($var) -> $var is sent to the console on the line this statement is > made with the statment "now watching 'var'.. init value "x", and then each > time it changes it is updated in the console. > > traceStack() -> as trace, but the current stack is reported. > traceAll() Return all variables in local scope and the current stack. > stop() Halt execution as die or exit, unlike them it's arguments are sent to > console instead of browser. > > On Tue, Apr 19, 2011 at 10:35 AM, Michael Morris wrote: > > > […] --- ## #51942 — Michael Morris — 2011-04-20T12:05:58+00:00 URL: https://externals.io/message/51546#51942 · In reply to: #51941 Those userland solutions (I've written a few myself) send the output as part of the html file that is being composed, or they write it to a file which you then later open up. Which is fine. This takes advantage of the fact that this CLI client, which will *not* be running as a daemon, will have an open terminal window for it for as long as it persists until the process is stopped with CTRL-C. Sending output to that terminal window would be *very* useful in my opinion, hence the call for trace. Essentially, trace is "echo" to that terminal window, or "print_r" to that window if it is given an object or array. The userland solutions you mention can later be enhanced to take advantage of this trace function when they are running in the CLI webserver environment if their authors so choose. So can this be done now? Yes and no - Yes in the sense that, with a little creative working around, we can get the debug data. No in that the proposed trace statement has two key properties the userland solutions do not and CANNOT have: 1) It sends to the CLI webserver terminal if one exists. 2) If one does not exist the statement is discarded like comment text. > I'm not sure if this is needed when there are already solutions for this. > eg, syslog, error_log, or other userland solutions like Zend_Log, > sfLogger, etc. > > Cheers, > David > > > > […] > command > > […] > each > > […] > to > > […] > statement > > […] > modes > > […] --- ## #51943 — johannes@schlueters.de — 2011-04-20T12:24:38+00:00 URL: https://externals.io/message/51546#51943 · In reply to: #51942 > This takes advantage of the fact that this CLI client, which will*not* be > running as a daemon, will have an open terminal window for it for as long as > it persists until the process is stopped with CTRL-C. Sending output to > that terminal window would be*very* useful in my opinion, hence the call > for trace. Essentially, trace is "echo" to that terminal window, or > "print_r" to that window if it is given an object or array. `error_log()` output should go there by default. (didn't check the patch) you can route everything there. I don't think it's good to add tons of extra functions for that. johannes --- ## #51944 — Jordi Boggiano — 2011-04-20T12:35:36+00:00 URL: https://externals.io/message/51546#51944 · In reply to: #51943 > > > > > […] > > `error_log()` output should go there by default. (didn't check the patch) > you can route everything there. I don't think it's good to add tons of > extra functions for that. I think the difference with the trace() approach is that it could be a NOOP by default, and just print to console when running the php httpd, so you could theoretically leave debug output in, and I will leave everyone the liberty to interpret that as a good or bad idea. Cheers -- Jordi Boggiano @seldaek :: http://seld.be/ --- ## #51945 — Matthew Weier O'Phinney — 2011-04-20T13:20:27+00:00 URL: https://externals.io/message/51546#51945 · In reply to: #51942 > --e0cb4e43cce199248e04a15872c6 > Content-Type: text/plain; charset=ISO-8859-1 > > Those userland solutions (I've written a few myself) send the output > as part of the html file that is being composed, or they write it to a > file which you then later open up. Which is fine. > > This takes advantage of the fact that this CLI client, which will > *not* be running as a daemon, will have an open terminal window for it > for as long as it persists until the process is stopped with CTRL-C. > Sending output to that terminal window would be *very* useful in my > opinion, hence the call for trace. Essentially, trace is "echo" to > that terminal window, or "print_r" to that window if it is given an > object or array. I'm going to correct one of your assumptions here, which is "or they write it to a file." Zend_Log has an adapter-based approach to log writers. How the writer performs its task is up to the developer. We have writers that write to web services and databases. Our "file" writer is actually labelled "Stream", because it uses streams. This means you can use "php://stdout" to write to. Additionally, you can have many writers attached to the logger. So, you could have one writing to a file, and another to STDOUT. This is all configurable via a factory. And ZF's solution isn't unique; I've seen other logging solutions that do similarly. My point is: don't dismiss userland solutions out-of-hand; they may offer flexibility that a language-based solution cannot provide. > The userland solutions you mention can later be enhanced to take > advantage of this trace function when they are running in the CLI > webserver environment if their authors so choose. > > So can this be done now? Yes and no - Yes in the sense that, with a > little creative working around, we can get the debug data. No in that > the proposed trace statement has two key properties the userland > solutions do not and CANNOT have: > > 1) It sends to the CLI webserver terminal if one exists. > 2) If one does not exist the statement is discarded like comment text. As I noted above, you can open a stream to php://stdout. If it's unavailable, the text is basically discarded. > > > > […] > > --e0cb4e43cce199248e04a15872c6-- -- Matthew Weier O'Phinney Project Lead | matthew@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc --- Next page: https://externals.io/message/51546.md?page=2