php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22057 fgets function failure
Submitted: 2003-02-04 15:29 UTC Modified: 2003-02-05 10:03 UTC
From: elazizli at celiknet dot com Assigned:
Status: Not a bug Package: Filesystem function related
PHP Version: 4.3.0 OS: win32
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: elazizli at celiknet dot com
New email:
PHP Version: OS:

 

 [2003-02-04 15:29 UTC] elazizli at celiknet dot com
The following code used to return correct  headers for the requested page whit PHP 4.2.3.. $host, $port and $path variables are dynamically assigned by the script.
Now it doesn't work without any configuration change other than PHP upgrade. It returns a three-character string instead of the requested information. Is this because of the change applied to fgets function in PHP 4.3? Same code stopped working when migrated to 4.3 from 4.2.3, no module or configuration change happened during upgrade, same settings were kept.



$fp = fsockopen($host,$port);

$request =
"GET $path HTTP/1.1
Host: $host$port
Accept: */*
Accept-Charset: iso-8859-1
Accept-Encoding: identity

";
    fputs($fp,$request);
    $answer = fgets($fp,4096);

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-02-04 15:39 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

fgets() will only return a single line of data or the requested number of bytes, which ever one is smallest will be returned. In case of HTTP, the 1st line that will be sent to you by the webserver will be the response code, which in many cases is just a number 3 bytes long.
 [2003-02-04 15:59 UTC] elazizli at celiknet dot com
PHP manual doesn't tell why this function start to give an error in version 4.3 while working fine with 4.2.x.

I also tried less efficient ways of getting http headers just for test purposes and such 3-character long string never appears. That inefficient method returns same string fgets in 4.2.3 used to return. PHP manual says the function was modified regarding a fix about binaries. does that affect the result?

As I say it is not about HTTP or server settings. Same code is not working with 4.3 although it worked fine with 4.2.3. 

Sorry but your answer doesn't help to explain why this error happened after upgrading to 4.3 while keeping all server and configuration settings same.
 [2003-02-04 16:13 UTC] sniper@php.net
What error? And please give us a complete (but short!) example script..

 [2003-02-04 16:17 UTC] iliaa@php.net
Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

The manual clearly states that no more then 1 line will be read by fgets() function. This is not something new, the old code worked in the exact same manner.
In my tests the outputs of PHP 4.2.3 & 4.3.0 are identical:
PHP 4.2.3
string(17) "HTTP/1.1 200 OK
"

PHP 4.3.0
string(17) "HTTP/1.1 200 OK
"

 [2003-02-05 01:25 UTC] elazizli at celiknet dot com
I am well aware of what manual states and how the function works. You are
saying you get same results from both versions. Which configuration of
server settings you use? Did you try all, so you can be so sure?

I use Apache 1.3.27 on Windows and upgraded from PHP 4.2.3 to 4.3.0 recently
by keeping all settings same and this problem occurred.  How would you
explain same function code returns two different responses in different
versions?



Server: Apache/1.3.27 (Win32) PHP/4.3.0

PHP 4.3.0

response:    "fbc" or something similar.

PHP 4.2.3

response:    "HTTP/1.1 200 OK"



And also this doesn't happen for all websites I tried. It seems the function
is having some serious problem with certain server configurations. This
wasn't the case for 4.2.3.

I hope you are not approaching all bug reports as you did to mine. Maybe I
should have mentioned my server but still you are approaching with a
prejudice of dealing with a dummy user rather than trying to make sure the
function works with all platform and distribution versions. You could have
asked more details rather than putting it into a "dummy user wandering in
bug pages" case from the first reply.
 [2003-02-05 01:59 UTC] wez@php.net
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


"response:    "fbc" or something similar."
                    ^^^^^^^^^^^^^^^^^^^^
How about a real error report?
If you can't be bothered to spend the time to give us
precise details, why should we sit here guessing what
your problem is?

Are you sure that your web server isn't sending back data using the chunked transfer encoding? (read the specs for HTTP 1.1!).

If your code doesn't handle chunked encoding, use HTTP 1.0 instead.

If you are *absolutely* 100% sure that your script isn't broken as far as HTTP is concerned, how about giving us more details on the remote server?  Is it something we can access so that we can see the same problem?

Don't start complaining to us about how nicely you have been treated; so far you have wasted 2 peoples time with insufficient data.  Please don't waste mine as well.

 [2003-02-05 02:49 UTC] elazizli at celiknet dot com
I said I just upgraded to 4.3.0 and kept all settings of server and PHP same on Windows OS. fgets function stated to give error after upgrade while working fine with older version. I believe the changes made in version 4.3.0 regarding file functions are causing this error.

I have been trying to explain sim?ply, without bothering with script codes, that fgets function doesn't return requested information in 4.3.0 while working fine in 4.2.3.

My server settings and code has been same for both PHP versions but new one doesn't work.

Whose time has been wasted? Yours or mine?
From the first message you didn't get what I meant: server/ php settings and the code were same except version upgrade to 4.3.0. Yet it didn't work. I wasted whole day to explain this to so-called experts.  So why bother with more details. 

Your guys have been treating me as a "dummy guy" looking for manual information and apparently can't understand basic english unless some PHP code is sent with it. If something stops working in new version although it isn't supposed to or intended to do so, THAT IS AN ERROR. Instead of asking what you need you accused me. I don't have anymore time to waste with people who have no respect for me.

You don't really even read my messages. Otherwise you wouldn't ask about an error in my server settings etc. since I reported several times that everything, including code, was same except upgrading to 4.3.0

The beloved PHP manual mentions only handling binaries better as a change in fgets function in 4.3.0, not any case of returning wrong data in this new version.
 [2003-02-05 03:33 UTC] sniper@php.net
http://bugs.php.net/how-to-report.php

I tried to ask what error you get..it would help a lot to
know that. Is it some PHP error message?

It's not easy to try guessing what you might mean so please
check your attitude. FYI: 99% of bug reports are actually
support questions which in the end just take our time
out of fixing the real bugs..

 [2003-02-05 10:03 UTC] pollita@php.net
Elazizli-

  Let's look at facts together shall we?

1) The behavior (output) of your script changed between 4.2.3 and 4.3.0 without having changed the content of the script or any other server setting.  Yes, this implies a PHP bug.

2) fgets() is an extremely common function and there have been no similar reports of it failing as you state.  This implies some quirk in your setup.

3) Your script *HAS* been tested as thoroughly as possible given the information you have provided.  It's not failing for anyone else.  This enforces the conclusion in #2.

So we have a dilema.  Some facts point one way, some point another.  This means its time for "Debugging 101", hence the questions.

If there's a bug, I'd love to fix it.  So would Ilia or Wez or Sniper, or any of the others silently following this thread.  But we NEED you to cooperate.  

Without meaningful feedback all we can do is guess, and everyone's guess right now seems to be that there's some non presenting bug in your script which just happened to work with 4.2.3, and that whatever allowed that buggy code to opperate prior to 4.3.0 was fixed.

Provide *complete* scripts (not scripts that comment '$foo is defined elsewhere' or 'I do blah later on').

Provide *exact* output.  "An Error Message" is non descript.  Is it a PHP generated error message?  Is it a webserver generated error message?  What *IS* the text of the error message?  Do it stop execution or simply warn?

Looking forward to working with you to improve the quality of PHP.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Apr 24 09:01:28 2024 UTC