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

go to bug id or search bugs for

Bug #27515 php -b still not working
Submitted: 2004-03-06 17:59 UTC Modified: 2006-01-02 08:51 UTC
Votes:9
Avg. Score:4.6 ± 0.8
Reproduced:7 of 7 (100.0%)
Same Version:4 (57.1%)
Same OS:7 (100.0%)
From: verdy_p at wanadoo dot fr Assigned:
Status: Wont fix Package: CGI/CLI related
PHP Version: 4.3.4 OS: Windows
Private report: No CVE-ID: None
View Developer Edit
 [2004-03-06 17:59 UTC] verdy_p at wanadoo dot fr 
Description:
------------
I know this bug has already been submitted, but as it has been closed multiple times and developers only look at open bugs, they don't see this one which affects the current LATEST stable version of PHP for Windows, both in the installer version and in the manually installed ZIP file.

When will FastCGI work on Windows? Why is it said to have been fixed when "php -b" is simply not supported.

C:\> php\php -v
PHP 4.3.4 (cgi-fcgi) (built: Nov  2 2003 23:47:22)
Copyright (c) 1997-2003 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies



Expected result:
----------------
FastCGI is the MOST important SAPI for PHP, the MSOT secure, the fastest and the one chosen by almost all ISPs for these reasons, notably because of the complete separation from the web server, and the possibility to run it on multiple hosts working in parallel for a cluster of webservers.

Please enable it on a stable version. Or at least come back to the latest stable version and branch it to include the needed fix for options, and recreate the distributions for Windows (ZIP and installer).

Then make sure the fix is applied in the next release by looking at release candidate branches, so that the fix is not forgotten!

Actual result:
--------------
C:\> php\php -b 127.0.0.1:6000
Error in argument 1, char 2: option not found b
Usage: php [-q] [-h] [-s] [-v] [-i] [-f <file>]
       php <file> [args...]
  -a               Run interactively
  -b <address:port>|<port> Bind Path for external FASTCGI Server mode
  -C               Do not chdir to the script's directory
  -c <path>|<file> Look for php.ini file in this directory
  -n               No php.ini file will be used
  -d foo[=bar]     Define INI entry foo with value 'bar'
  -e               Generate extended information for debugger/profiler
  -f <file>        Parse <file>.  Implies `-q'
  -h               This help
  -i               PHP information
  -l               Syntax check only (lint)
  -m               Show compiled in modules
  -q               Quiet-mode.  Suppress HTTP Header output.
  -s               Display colour syntax highlighted source.
  -v               Version number
  -w               Display source with stripped comments and whitespace.
  -z <file>        Load Zend extension <file>.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-03-07 22:54 UTC] iliaa@php.net 
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

This option is avaliable only for non-windows systems.
 [2004-03-08 00:15 UTC] verdy_p at wanadoo dot fr 
I really can't understand your constant response to this problem. All release notes are saying that the FastCGI bugs were fixed for Win32, but none of them indicate that the bug resolution was in fact REMOVING FastCGI from the Win32 build.

The release notes are simply wrong, and CGI is not an alternative option due to the number of processes it creates an a server, and embedded server API is not also an option due to the memory leaks and security issues which can't be controled in the web server...

I really cannot understand what is the issue with FastCGI which would forbid it to run on Windows...

So without FastCGI, one cannot simply run PHP on Windows to implement a decent web service supporting lots of requests, as we are restricted to use only CGI... with lots of memory and too much processor overhead.

Do we need to run PHP on a separate Unix/Linux box and not on the Windows web server ???

I still persist that this is a bug when php -v says it is "cgi/fastcgi" and when php -h says that the -b option is supported, and the release notes say it is supported and all past bugs in FastCGI on windows were fixed.

Currently PHP lies on its web site and in its software.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri May 09 10:01:28 2025 UTC