php-windows Digest 23 Mar 2004 13:59:38 -0000 Issue 2178
Topics (messages 23234 through 23236):
Re: The specified CGI application misbehaved by not returning acomplete set of HTTP
headers.
23234 by: Svensson, B.A.T. (HKG)
Re: Major apache start error!!
23235 by: Sumito_Oda
Problems with PHP5 RC1
23236 by: memoimyself.yahoo.com.br
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
Your suggestion to redirect stderr to stdin works splendid.
On Mon, 2004-03-22 at 12:44, DvDmanDT wrote:
> I would suspect popen() happends to output STDERR, and that dir returns some
> STDERR when no files are found, or when the argument is invalid.. And if so,
> the STDERR message would get output directly to the webserver, and if it
> contains two newlines (which it does really I think), the webserver wouldn't
> get a complete set of headers (which it's complaining about)...
>
> Add this at the end of your command: 2 > &1, like this:
>
> $ListDir = "dir $Dir\\*.$pattern 2>&1";
>
> Also, I think this would be even better:
> $ListDir = "dir \"$Dir\\*.$pattern\" 2>&1";
>
> Happy coding!
> --
> // DvDmanDT
> MSN: dvdmandt$hotmail.com
> Mail: dvdmandt$telia.com
> "B.A.T. Svensson" <[EMAIL PROTECTED]> skrev i meddelandet
> news:[EMAIL PROTECTED]
> > I am curious about why the following error:
> >
> >
> > "The specified CGI application misbehaved by not returning a complete
> > set of HTTP headers."
> >
> > is generated while trying to read data from an empty pipe.
> >
> >
> >
> > **********************************************************
> >
> > DISCUSSION:
> >
> > I have an (working) application that renders an out put in
> > side a table based on the menu selection the user does.
> >
> > Basically the web pages is organized as such:
> >
> > +-----------+
> > | PAGE HEAD |
> > +-+---------+
> > |M| |
> > |E| OUTPUT |
> > |N| VIEW |
> > |U| |
> > . . .
> > . . .
> > . . .
> > +-+---------+
> > | PAGE FOOT |
> > +-----------+
> >
> >
> >
> > Now, if I select a certain menu choices, and the system is in a
> > certain state (will soon explain this) then the CGI error "The
> > specified CGI application misbehaved by not returning a complete
> > set of HTTP headers." occurs.
> >
> > What trigger then the error then, well, it is derived from a
> > function like this:
> >
> > (This function will output its display data the "OUTPUT VIEW".)
> >
> > function ug_show_files($Dir, $pattern, $Message)
> > {
> > print "<pre>$Message\r\n";
> >
> > $ListDir = "dir $Dir\\*.$pattern";
> > if ($pipe = popen($ListDir, "r")) {
> >
> > while (!feof($pipe)) {
> > $line = trim(fgets($pipe));
> > print "$line\n";
> > }
> >
> > pclose($pipe);
> > }
> >
> print"<pre>";
> > return "ok";
> > }
> >
> > The above code list a given directory based on $pattern.
> > However whenever no files are found, then the above CGI error
> > is generated - but never if there is a content found. I was a
> > bit confused about this, since the only difference is that the
> > directory listing does not generate an output, so in my point
> > of view it should work, but it did not.
> >
> >
> > I boiled down the problem to be related with fgets() - the error
> > occurs when the directory listing does not return anything, so I
> > thought I would be able to get rid of the error by writing the code
> > like this instead:
> >
> > function ug_show_files($Dir, $pattern, $Message)
> > {
> > print "<pre>$Message\r\n";
> >
> > $ListDir = "dir $Dir\\*.$pattern";
> > if ($pipe = popen($ListDir, "r")) {
> >
> > $a = fgets($pipe)
> > while (!feof($pipe)) {
> > $line = trim($a);
> > print "$line\n";
> > $a = fgets($pipe);
> > }
> > pclose($pipe);
> > }
> >
> print"<pre>";
> > return "ok";
> > }
> >
> >
> > However the error persisted whenever the directory list
> > was empty so I changed the code to look like this:
> >
> > function ug_show_files($Dir, $pattern, $Message)
> > {
> > print "<pre>$Message\r\n";
> >
> > $ListDir = "dir $Dir";
> > if ($pipe = popen($ListDir, "r")) {
> >
> > while (!feof($pipe)) {
> >
> > $line = trim(fgets($pipe));
> > if (strpos($line, ".$pattern")) {
> > print "$line\n";
> > }
> >
> > }
> > pclose($pipe);
> > }
> >
> print"<pre>";
> > return "ok";
> > }
> >
> > And after this the pages stop returning an error. Now to the
> > question; why is it that fgets() generates this CGI error
> > when fgets() read from an empty pipe?
--- End Message ---
--- Begin Message ---
Hi,
>Sorry, forgot to mention that I am on WinXP Pro
Did you copy php4ts.dll to c:/windows/system32
or a proper directory?
http://www.php.net/manual/en/install.apache.php
http://www.php.net/manual/en/install.windows.php
Moreover, you might have to add the description of
AddModule directive for mod_php4.c to httpd.conf.
--
Sumito_Oda mailto:[EMAIL PROTECTED]
--- End Message ---
--- Begin Message ---
I have successfully installed previous versions of PHP dozens of times, under Windows,
Linux and FreeBSD, so I'm not exactly a newbie having a go at his first install. I've
tried
to report the problems I relate below to the PHP bugs knowledge base, but
bugs.php.net has been down for a couple of days.
I'm trying to run PHP5 RC1 on a Windows 2000 test server with Apache 2.0.49. I
downloaded the PHP5 RC1 package and installed it according to the instructions in the
install.txt file (which is essentially the same as for previous 4.x versions). (Note:
I tried
the installation for the first time with Apache 2.0.47, but have since upgrated to the
latest stable version, to no avail.)
Upon installation, when I start Apache again, I get an error message to the effect
that
php4ts.dll cannot be found in the system32 directory or any of the system paths. This
is
curious because if anything is missing, it should be php5ts.dll, not php4ts.dll. If I
rename php5ts.dll to php4ts.dll, I stop getting the error message, so there's clearly
something in the entrails of PHP5 that expects to find php4ts.dll. Renaming the file
is
not exactly a pretty solution, though, so I'm hoping this problem will be corrected in
the
final release.
I have of course edited httpd.conf so that it now contains the line
LoadModule php5_module "c:/php/php5apache2.dll"
instead of
LoadModule php4_module "c:/php/sapi/php4apache2.dll"
I have also checked the new php.ini file to make sure that it contains valid paths
(e.g.
extension_dir = "C:\PHP\ext\"). Everything looks fine.
I use the DOM XML extension all the time and noticed that "php_domxml" is no longer
an option in the extensions section of php.ini, so I assume that DOM XML is now
bundled with PHP. As a matter of course, phpinfo() tells me that DOM/XML is enabled
and that the libxml version is 2.5.11. However, when trying to use domxml_version(),
domxml_new_doc(), domxml_open_mem() or any other DOM XML function, I get a "call
to undefined function" error. If these functions now have new names, they're not
listed in
the online documentation. The same happens with the MySQLi extension, which is no
longer an option in php.ini but none of its functions work either.
The extensions directory is there and is pointed to correctly by php.ini; all PHP
files are
in c:\php and the sub-directories are exactly the same as in the distribution package;
httpd.conf has been properly edited (and in fact Apache issues no error messages); my
system path variable contains c:\php. What else can I possibly do to get PHP5 to work
properly?
Erik
--- End Message ---
