php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #67884 Doing a request to itself causes a lock
Submitted: 2014-08-22 03:28 UTC Modified: 2014-10-16 17:24 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: jgmdev@php.net Assigned:
Status: Not a bug Package: Built-in web server
PHP Version: 5.5.15 OS: Linux (Archlinux)
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
9 + 46 = ?
Subscribe to this entry?

 
 [2014-08-22 03:28 UTC] jgmdev@php.net 
Description:
------------
The built-in testing webserver locks down if current executing script makes a request using file_get_contents, get_headers, as any function which supports the http:// streams that makes a request to itself.

With the router test script provided try:

php -S localhost:8001 router-test.php

wget http://localhost:8001/something (works fine)

wget http://localhost:8001/ (lock when requesting /something)


Test script:
---------------
<?php
$path = "";

if(isset($_SERVER["PHP_SELF"]))
{
    $path .= ltrim($_SERVER["PHP_SELF"], "/");
}

if($path == "something")
{
    print "something";
}
else
{
    print "nothing";
    
    // Locks here
    print file_get_contents("http://localhost:8001/something");
}


Expected result:
----------------
Request to http://localhost:8001/ should print nothingsomething

Actual result:
--------------
The php built-in webserver locks when trying to request http://localhost:8001/something.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-08-22 04:17 UTC] requinix@php.net 
Isn't the server single-threaded? The docs say right there at the top "PHP applications will stall if a request is blocked".
 [2014-08-22 13:10 UTC] jgmdev@php.net 
I tested with ab -c 100 -n 1000 http://localhost:8001/ and a router file that doesn't request it self:

<?php print "something";

And here are the results, which shows that the built-in server does supports concurrency/threading (unless it is happening so fast that feels like threading):

Concurrency Level:      100
Time taken for tests:   0.075 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      118000 bytes
HTML transferred:       7000 bytes
Requests per second:    13335.82 [#/sec] (mean)
Time per request:       7.499 [ms] (mean)
Time per request:       0.075 [ms] (mean, across all concurrent requests)
Transfer rate:          1536.75 [Kbytes/sec] received

Also the meaning of "PHP applications will stall if a request is blocked" isn't clear.
 [2014-08-22 18:45 UTC] requinix@php.net 
With a sleep(1) in the router script I get

Concurrency Level:      100
Time taken for tests:   1000.604 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      121000 bytes
HTML transferred:       0 bytes
Requests per second:    1.00 [#/sec] (mean)
Time per request:       100060.414 [ms] (mean)
Time per request:       1000.604 [ms] (mean, across all concurrent requests)
Transfer rate:          0.12 [Kbytes/sec] received

Given X=number of concurrent requests served by PHP, and a sleep(1) to account for the various "per second"-s, the report will say:
- Time taken: 1000 [total time] / X
- Requests per second: X
- Mean time per request: 100 [concurrent requests by AB] * 1000 [msec. each] / X

So it's not concurrent. Besides, I don't see any threading or forking going on in the source code.
 [2014-08-22 18:59 UTC] jgmdev@php.net 
I see :(, looking at the code polling was used, well I'm not going to be able to test my system using the built-in server. Something like http://en.wikipedia.org/wiki/Multiple_asynchronous_periodic_polling would solve the issue, wonder how much work it would be to implement that.
 [2014-10-16 17:24 UTC] johannes@php.net
-Status: Open +Status: Not a bug
 [2014-10-16 17:24 UTC] johannes@php.net 
The embedded web server is for testing purpose and not meant as a full web server. This limitation along with others (like missing vhost support etc.) is by design and we don't have any plans to change that as there are multiple good web servers already which work nicely with PHP.
 [2017-07-27 12:18 UTC] cohan at icnerd dot com 
> The embedded web server is for testing purpose and not meant as a full web server [..] there are multiple good web servers already which work nicely with PHP.

Any chance of this one being re-looked at? There are multiple dev use cases for this. For example both Laravel and WP CLI use the PHP built in server to test development with a simple "serve" command. Unfortunately if you happen to make a request within a script (such as to an API, also being tested) everything locks up.

At the very least some form of error message to stderr if we're attempting to make a request to ourselves. At the moment there's no indication as to where the error is actually occurring.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Apr 16 05:01:29 2024 UTC