Hello everyone.
Currently, I am working on a project that allows PHP applications to be developed with a GUI frontend based on Chromium - and later on CEF. For this to work properly, I am spawning a new Chromium process with some command line switches to allow customization of the launch. This means, I can pass in the URL which should be opened, and disable features such as translation and alike. However, the problem is the HTTP backend. Currently, I am using a PHP script in the same process as the "watching" process - which is basically a while loop that awaits for a client connection. By using the pthreads extension, I am also handling events that are received by the Remote Debug Protocol via a WebSocket connection (PHP acting as a client here). As you can see, this is a little chaos. So I have the event listener, the Webserver and process watcher for Chromium in seperated threads. Once the browser is quit, I have to use posix_kill to make sure the webserver dies as well - because it simply wouldn't.
So I got to the conclusion that I may change the logic, and remove the webserver, and replace it by another spawned process of the PHP CLI HTTP server. The problem is, I'd want to customize it some. Like, customize error pages, logging, etc.
I am also curios about something else. Back in some time, the PHP manual read that the HTTP server is "for development only". The problem is, I do not want to package an apache webserver into the bundle - or do some nodejs scripting for some webserver. I'd like to stay on a PHP basis.
Would be great if you can explain some things to me here!
Related links for those curios:
The actual project, drag0n: https://github.com/IngwiePhoenix/drag0n
Deskshell (I maintain a fork and build the MacOS port): https://github.com/sihorton/appjs-deskshell
The current WebSocket client I am using for communication: https://github.com/Devristo/phpws
The Webserver was somewhere on google, the original file can be found within drag0n, to be exact, here: https://github.com/IngwiePhoenix/drag0n/blob/master/drag0n.app/Contents/System/lib/php/WebServer.php
Kind regards, Ingwie
Hi Kevin,
On Wed, Nov 6, 2013 at 10:06 AM, Kevin Ingwersen
ingwie2000@googlemail.comwrote:
I am also curios about something else. Back in some time, the PHP manual
read that the HTTP server is "for development only". The problem is, I do
not want to package an apache webserver into the bundle - or do some nodejs
scripting for some webserver. I'd like to stay on a PHP basis.
"For development only" note is there because cli server crash means stopped
service.
If there is watch dog that restart cli server, then it's ok to use with any
purpose as long as
users don't care for restrictions/stability/security.
(For instance, daemon tools by DJB may be used as good watch dog.)
I think no one objects making cli server more like full featured web
server.
Pull requests will be welcomed.
Anyway, the original author was made cli server to be used like Mongrel in
Ruby.
That's the main reason of "for development only" besides the early stage of
cli
server development.
Current manual
http://php.net/manual/en/features.commandline.webserver.php
states
"This web server is designed for developmental purposes only, and should
not be used in production."
at the beginning of the page. It may be too much now.
How about make it a note some thing like this?
"Note: Build-in web server is intended for web application development. Use
in production environment is
discouraged."
Any comments?
--
Yasuo Ohgaki
yohgaki@ohgaki.net
On Wed, Nov 6, 2013 at 10:06 AM, Kevin Ingwersen <
ingwie2000@googlemail.com> wrote:I am also curios about something else. Back in some time, the PHP manual
read that the HTTP server is "for development only". The problem is, I do
not want to package an apache webserver into the bundle - or do some nodejs
scripting for some webserver. I'd like to stay on a PHP basis."For development only" note is there because cli server crash means
stopped service.
If there is watch dog that restart cli server, then it's ok to use with
any purpose as long as
users don't care for restrictions/stability/security.
(For instance, daemon tools by DJB may be used as good watch dog.)I think no one objects making cli server more like full featured web
server.
Pull requests will be welcomed.Anyway, the original author was made cli server to be used like Mongrel in
Ruby.
That's the main reason of "for development only" besides the early stage
of cli
server development.Current manual
http://php.net/manual/en/features.commandline.webserver.php
states"This web server is designed for developmental purposes only, and should
not be used in production."at the beginning of the page. It may be too much now.
How about make it a note some thing like this?"Note: Build-in web server is intended for web application development.
Use in production environment is
discouraged."Any comments?
s/Build-in/Built-in/
BTW, Manual also states "Requests are served sequentially.", but it does
not block
concurrent requests. It may be misleading and not needed.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
It doesn't handle petitions concurrently, which bars its use on most
production environments.
Hi Angel,
It doesn't handle petitions concurrently, which bars its use on most
production environments.
What do you mean?
Could you explain little more?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Angel,
On Wed, Nov 6, 2013 at 4:32 PM, Ángel González <keisial@gmail.com
mailto:keisial@gmail.com> wrote:It doesn't handle petitions concurrently, which bars its use on most production environments.What do you mean?
Could you explain little more?Regards,
I was refering to the piece you mentioned before:
BTW, Manual also states "Requests are served sequentially.", but it does
not block
concurrent requests. It may be misleading and not needed.
It may be easier to explain with an example:
$ echo '<?php sleep(10); echo "Hi";' > a.php
$ echo '<?php echo "World";' > b.php
$ php -S 127.0.0.1:8080
If you now request a.php and b.php, using separate connections.
a.php will take 10 seconds, but b.php will also take 10 seconds even
though it is quick, as it will need to
wait for a.php to finish.
Hi Angel,
It doesn't handle petitions concurrently, which bars its use on most
production environments.What do you mean?
Could you explain little more?Regards,
I was refering to the piece you mentioned before:
BTW, Manual also states "Requests are served sequentially.", but it does
not block
concurrent requests. It may be misleading and not needed.It may be easier to explain with an example:
$ echo '<?php sleep(10); echo "Hi";' > a.php
$ echo '<?php echo "World";' > b.php
$ php -S 127.0.0.1:8080If you now request a.php and b.php, using separate connections.
a.php will take 10 seconds, but b.php will also take 10 seconds even
though it is quick, as it will need to
wait for a.php to finish.
Thank you.
Now I see what you mean.
CLI server is accepts multiple requests, but scripts are executed one by one
because there is only one PHP in there.
I'll update the manual 'requests' to 'script' also.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
Thank you.
Now I see what you mean.CLI server is accepts multiple requests, but scripts are executed one by
one
because there is only one PHP in there.I'll update the manual 'requests' to 'script' also.
CLI server has only basic ZTS support and cannot execute scripts
concurrently.
It would be nice if CLI server supports ZTS fully and execute script with
ZTS mode.
It's good for ZTS debugging.
Anyone?
--
Yasuo Ohgaki
yohgaki@ohgaki.net
CLI server has only basic ZTS support and cannot execute scripts
concurrently.
It would be nice if CLI server supports ZTS fully and execute script with
ZTS mode.
It's good for ZTS debugging.Anyone?
Instead of starting down the path to write a threaded web server, it
would be a lot easier, and much more robust, to simply add php-fpm
support to the CLI server. But we would also be veering quite far from
the original point of the CLI server with something like that.
-Rasmus
hi,
CLI server has only basic ZTS support and cannot execute scripts
concurrently.
It would be nice if CLI server supports ZTS fully and execute script with
ZTS mode.
It's good for ZTS debugging.
For zts debugging you can look at https://github.com/johannes/pconn-sapi
which I initially wrote to help testing persistent connection-like
things but which also supports threaded use. See also
http://schlueters.de/blog/archives/166-Testing-persistent-connection-and-thread-safety-features-in-PHP.html
johannes
I'm also in agreement with updating the docs.
IMO I think the CLI server can be safely used for small local (
http://localhost) or offline web apps .
On Tue, Nov 12, 2013 at 5:50 AM, Johannes Schlüter
johannes@schlueters.dewrote:
hi,
CLI server has only basic ZTS support and cannot execute scripts
concurrently.
It would be nice if CLI server supports ZTS fully and execute script with
ZTS mode.
It's good for ZTS debugging.For zts debugging you can look at https://github.com/johannes/pconn-sapi
which I initially wrote to help testing persistent connection-like
things but which also supports threaded use. See alsojohannes
Hi all,
I'm also in agreement with updating the docs.
IMO I think the CLI server can be safely used for small local (
http://localhost) or offline web apps .
How about change the manual as follows?
Any correction, improvement is appreciated.
Index: commandline.xml
--- commandline.xml (リビジョン 332115)
+++ commandline.xml (作業コピー)
@@ -1606,12 +1606,15 @@
</para>
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
I'm also in agreement with updating the docs.
IMO I think the CLI server can be safely used for small local (
http://localhost) or offline web apps .How about change the manual as follows?
Any correction, improvement is appreciated.Index: commandline.xml
--- commandline.xml (リビジョン 332115)
<para> - This web server is designed for developmental purposes only, and should not - be used in production. + Multiple requests are handled concurrently, but PHP scripts are + served sequentially. It blocks requests and PHP scripts if a script + stalled. </para> <para> - Requests are served sequentially. + This web server is designed for developmental purposes mainly, and + it is not aimed to be a full featured web server. Use of built-in + web server under public internet is discouraged. </para> <para>
+++ commandline.xml (作業コピー)
@@ -1606,12 +1606,15 @@
</para>
Correction. It does block script, but not request.
Any correction, improvement is appreciated.
Index: commandline.xml
--- commandline.xml (リビジョン 332115)
+++ commandline.xml (作業コピー)
@@ -1606,12 +1606,14 @@
</para>
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Correction. It does block script, but not request.
Any correction, improvement is appreciated.Index: commandline.xml
--- commandline.xml (êÓ¸çó 332115)
+++ commandline.xml (\m³Ôü)
@@ -1606,12 +1606,14 @@
</para><para>
- This web server is designed for developmental purposes only, and should
not- be used in production.
- Multiple requests are handled concurrently, but PHP scripts are
- served sequentially. It blocks PHP scripts if a scripts stalled.
</para>
I don't think the distinction is useful for the end user. At face
value readers might see it as contradictory: "is it concurrent or
sequential?". Or the description needs clarification to explain the
subtleties.
Also, consider this grammar/wording correction for the last sentence:
"PHP applications will stall if a request is blocked"
<para>
- Requests are served sequentially.
- This web server is designed for developmental purposes mainly, and
- it is not aimed to be a full featured web server. Use of built-in
- web server under public internet is discouraged.
</para>
Perhaps say:
This web server was designed to aid application development. It may
also be useful for testing purposes or for application
demonstrations that are run in controlled environments. It is not
intended to be a full-featured web server. It should not be used on
a public network.
Chris
--
christopher.jones@oracle.com http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
Hi Christopher,
On Fri, Nov 15, 2013 at 9:39 AM, Christopher Jones <
christopher.jones@oracle.com> wrote:
Correction. It does block script, but not request.
Any correction, improvement is appreciated.
Index: commandline.xml
--- commandline.xml (êÓ¸çó 332115)
+++ commandline.xml (\m³Ôü)@@ -1606,12 +1606,14 @@
</para><para>
- This web server is designed for developmental purposes only, and
should
not- be used in production.
- Multiple requests are handled concurrently, but PHP scripts are
- served sequentially. It blocks PHP scripts if a scripts stalled.
</para>I don't think the distinction is useful for the end user. At face
value readers might see it as contradictory: "is it concurrent or
sequential?". Or the description needs clarification to explain the
subtleties.Also, consider this grammar/wording correction for the last sentence:
"PHP applications will stall if a request is blocked"<para>
- Requests are served sequentially.
- This web server is designed for developmental purposes mainly, and
- it is not aimed to be a full featured web server. Use of built-in
- web server under public internet is discouraged.
</para>Perhaps say:
This web server was designed to aid application development. It may
also be useful for testing purposes or for application
demonstrations that are run in controlled environments. It is not
intended to be a full-featured web server. It should not be used on
a public network.
I'll use your correction.
Thank you.
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Johannes,
On Tue, Nov 12, 2013 at 7:50 PM, Johannes Schlüter
johannes@schlueters.dewrote:
CLI server has only basic ZTS support and cannot execute scripts
concurrently.
It would be nice if CLI server supports ZTS fully and execute script with
ZTS mode.
It's good for ZTS debugging.For zts debugging you can look at https://github.com/johannes/pconn-sapi
which I initially wrote to help testing persistent connection-like
things but which also supports threaded use. See also
Should this be in php-src, shouldn't?
I think it should.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
yohgaki-san,
For zts debugging you can look at https://github.com/johannes/pconn-sapi
which I initially wrote to help testing persistent connection-like
things but which also supports threaded use. See alsoShould this be in php-src, shouldn't?
I think it should.
If it is somehow integrated in the testsuite it can be added, till then
I see it as an experimental toy, and I prefer having toys outside the
source tree.
johannes
Hello Yasuo!
Thank you for your detailed response on this topic. I will look more into the source code of the CLI server and see what I can do. Sadly I am not a big C guy, but maybe the code will lead me into the right direction :)
Yes, I have a watch dog over each process that I spawn (a seperate thrad which is dedicated to the process). So if the server decides to shut down, I can bring it back up immediately. Thank you again for the hint.
I agree, the note should be changed some, it's a little bit misleading in my opinion. But I can see it's purpose, as most people will just use apache to serve PHP files.
Kind regards, Ingwie.
Am 06.11.2013 um 03:45 schrieb Yasuo Ohgaki yohgaki@ohgaki.net:
Hi Kevin,
I am also curios about something else. Back in some time, the PHP manual read that the HTTP server is "for development only". The problem is, I do not want to package an apache webserver into the bundle - or do some nodejs scripting for some webserver. I'd like to stay on a PHP basis.
"For development only" note is there because cli server crash means stopped service.
If there is watch dog that restart cli server, then it's ok to use with any purpose as long as
users don't care for restrictions/stability/security.
(For instance, daemon tools by DJB may be used as good watch dog.)I think no one objects making cli server more like full featured web server.
Pull requests will be welcomed.Anyway, the original author was made cli server to be used like Mongrel in Ruby.
That's the main reason of "for development only" besides the early stage of cli
server development.Current manual
http://php.net/manual/en/features.commandline.webserver.php
states"This web server is designed for developmental purposes only, and should not be used in production."
at the beginning of the page. It may be too much now.
How about make it a note some thing like this?"Note: Build-in web server is intended for web application development. Use in production environment is
discouraged."Any comments?
--
Yasuo Ohgaki
yohgaki@ohgaki.net
On Wed, Nov 6, 2013 at 10:06 AM, Kevin Ingwersen
ingwie2000@googlemail.comwrote:I am also curios about something else. Back in some time, the PHP manual
read that the HTTP server is "for development only". The problem is, I do
not want to package an apache webserver into the bundle - or do some nodejs
scripting for some webserver. I'd like to stay on a PHP basis."For development only" note is there because cli server crash means stopped
service.
If there is watch dog that restart cli server, then it's ok to use with any
purpose as long as
users don't care for restrictions/stability/security.
(For instance, daemon tools by DJB may be used as good watch dog.)
My recollection of the discussion at the time was that part of the
reasoning behind that note was security: the CLI server was a new
piece of code, and the public Internet is a pretty hostile place,
particularly for Web servers. Therefore the intention was to
discourage users from exposing the CLI server on anything other than
loopback and private networks.
It doesn't sound like that's a problem for Kevin, but I'm pretty sure
that was part of the context there.
Adam
Hi Adam,
My recollection of the discussion at the time was that part of the
reasoning behind that note was security: the CLI server was a new
piece of code, and the public Internet is a pretty hostile place,
particularly for Web servers. Therefore the intention was to
discourage users from exposing the CLI server on anything other than
loopback and private networks.It doesn't sound like that's a problem for Kevin, but I'm pretty sure
that was part of the context there.
I agree.
There was security issue in cli server in fact.
Current documentation is too much. IMHO.
It may be good time to modify our doc a little.
Any objection for making security warning to a note
that discourages use under internet?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hey!
Thank you all for your kind help, now I feel confident using the CLI HTTP server, and will very surely be doing so now.
As for the note, I'd have some idea for it:
Note: Due to the CLI Web server's low security, as it's intention wasn't for the internet or productive use, we would suggest you to use a more standard webserver such as Apache. However you can use it inside a network or for local development, as security concerns may not be as high in these areas (that is, if the IP the server is bound to is not publicy available).
Kind regards!
Am 06.11.2013 um 21:00 schrieb Yasuo Ohgaki yohgaki@ohgaki.net:
Hi Adam,
My recollection of the discussion at the time was that part of the
reasoning behind that note was security: the CLI server was a new
piece of code, and the public Internet is a pretty hostile place,
particularly for Web servers. Therefore the intention was to
discourage users from exposing the CLI server on anything other than
loopback and private networks.It doesn't sound like that's a problem for Kevin, but I'm pretty sure
that was part of the context there.I agree.
There was security issue in cli server in fact.
Current documentation is too much. IMHO.
It may be good time to modify our doc a little.Any objection for making security warning to a note
that discourages use under internet?Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Adam,
My recollection of the discussion at the time was that part of the
reasoning behind that note was security: the CLI server was a new
piece of code, and the public Internet is a pretty hostile place,
particularly for Web servers. Therefore the intention was to
discourage users from exposing the CLI server on anything other than
loopback and private networks.It doesn't sound like that's a problem for Kevin, but I'm pretty sure
that was part of the context there.I agree.
There was security issue in cli server in fact.
Current documentation is too much. IMHO.
It may be good time to modify our doc a little.Any objection for making security warning to a note
that discourages use under internet?
One reason for suggesting it is only for limited use is so that users
don't expect it to be (or to become) a fully featured web server.
Chris
--
christopher.jones@oracle.com http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html