5 ms·

Note that one of the main pushes for having this right in the core distribution was to improve our test framework. We can't rely on and end-user installed web s

by rll 14y ago

Note that one of the main pushes for having this right in the core distribution was to improve our test framework. We can't rely on and end-user installed web server for "make test" since we have no control over the configuration and the current approach of faking GET/POST/Cookie data for the CGI version only goes so far. Having an actual server where we can test things like opcode caching where the first and second request to the same resource hit wildly different code paths is a big win. It is also helpful during debugging. The less moving parts the better when you are sitting in gdb or Valgrind trying to track down a problem. For end users I think the most interesting feature is the ability to provide a router script that can wrap whatever frontend controller your framework is using. And some projects support it natively now. For example, in Symphony2 you download and untar it then just cd into the directory and start php -S localhost:1234 and off you go. But please, don't ever use this as a replacement for Apache/nginx as a user-visible web server.

chocolatebunny 14y ago
I don't understand the "make test" thing. If you're temporarily hosting pages for testing then doesn't that mean you have to also get something to pull those pages to validate them? If that's the case then why can't you just output stdout and validate the pages that way, with just some simple mechanism to pass post/cookie information as a parameter (much like how you would do it with wget).
- maratd 14y ago
  > I don't understand the "make test" thing. If you're temporarily hosting pages ... That has nothing to do with user code or hosting pages. Most people install PHP using their package manager (ie "yum install php"). Some people and those that maintain those packages, need to compile PHP from source code (PHP is written in C). The guys who develop PHP wrote thousands of tests that make sure that the binary that is compiled works properly. Those are the tests being referenced.
  - hythloday 14y ago
    Right, I think the poster you're replying to understands that. The question is that, given there's a command-line interpreter (php-cli), built as part of a normal build, which will execute PHP files and print the output, why do your tests need to go over HTTP at all?
    - maratd 14y ago
      > why do your tests need to go over HTTP at all? Just off the top of my head, how would you check file_get_contents which can take a url as a parameter? You can't just throw http://www.google.com/ http://www.google.com/ in there. You might be compiling on a machine that's not on the net, firewalled, etc. It becomes useful for functionality that normally relies on an external http server to work. The OP also mentions several more scenarios where it is useful and even necessary.
      - hythloday 14y ago
        That's a slightly different scenario - you're exercising client protocol functionality. (Incidentally, you don't need a webserver for that, you just need a very stupid socket server that will return a file. Also, file_get_contents looks like it can access ftp/ssh/gopher URLs so if you need a webserver, you also need servers that speak those other protocols).
    - rll 14y ago
      I thought I made that pretty clear with the opcode cache example. On the first request to a specific URL the script gets compiled, executed and cached. On the second request we skip the compile part and point the executor to the op_array in shared memory. We could do some hackish things where we try to persist that shared memory segment for the cli case, but that would be another artificial environment. We want to test as closely as possible to real production use cases and the best way to do that is to use an actual web server for any tests that rely on anything persisting across requests.
RobAley 14y ago
As a slight aside, I wonder if you would consider putting your name and/or relationship with PHP in your profile (particularly as you use "we" and "our" in relationship to PHP). It might help newcomers appreciate the particular (valuable) insight into PHP in your posts and put them into better context. It took me a while of reading your posts on here to realize who you were, and I note in a recent thread someone even asking how you learned so much about how PHP works...! Please keep commenting on PHP threads here, the balance and insight is very much welcome!

by rll 14y ago

chocolatebunny 14y ago

I don't understand the "make test" thing. If you're temporarily hosting pages for testing then doesn't that mean you have to also get something to pull those pages to validate them? If that's the case then why can't you just output stdout and validate the pages that way, with just some simple mechanism to pass post/cookie information as a parameter (much like how you would do it with wget).

maratd 14y ago
> I don't understand the "make test" thing. If you're temporarily hosting pages ... That has nothing to do with user code or hosting pages. Most people install PHP using their package manager (ie "yum install php"). Some people and those that maintain those packages, need to compile PHP from source code (PHP is written in C). The guys who develop PHP wrote thousands of tests that make sure that the binary that is compiled works properly. Those are the tests being referenced.
- hythloday 14y ago
  Right, I think the poster you're replying to understands that. The question is that, given there's a command-line interpreter (php-cli), built as part of a normal build, which will execute PHP files and print the output, why do your tests need to go over HTTP at all?
  - maratd 14y ago
    > why do your tests need to go over HTTP at all? Just off the top of my head, how would you check file_get_contents which can take a url as a parameter? You can't just throw http://www.google.com/ http://www.google.com/ in there. You might be compiling on a machine that's not on the net, firewalled, etc. It becomes useful for functionality that normally relies on an external http server to work. The OP also mentions several more scenarios where it is useful and even necessary.
    - hythloday 14y ago
      That's a slightly different scenario - you're exercising client protocol functionality. (Incidentally, you don't need a webserver for that, you just need a very stupid socket server that will return a file. Also, file_get_contents looks like it can access ftp/ssh/gopher URLs so if you need a webserver, you also need servers that speak those other protocols).
  - rll 14y ago
    I thought I made that pretty clear with the opcode cache example. On the first request to a specific URL the script gets compiled, executed and cached. On the second request we skip the compile part and point the executor to the op_array in shared memory. We could do some hackish things where we try to persist that shared memory segment for the cli case, but that would be another artificial environment. We want to test as closely as possible to real production use cases and the best way to do that is to use an actual web server for any tests that rely on anything persisting across requests.

RobAley 14y ago

As a slight aside, I wonder if you would consider putting your name and/or relationship with PHP in your profile (particularly as you use "we" and "our" in relationship to PHP). It might help newcomers appreciate the particular (valuable) insight into PHP in your posts and put them into better context. It took me a while of reading your posts on here to realize who you were, and I note in a recent thread someone even asking how you learned so much about how PHP works...! Please keep commenting on PHP threads here, the balance and insight is very much welcome!