|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #27466 fread bug reading large block of data from a socket
Submitted: 2004-03-02 13:48 UTC Modified: 2004-03-02 16:07 UTC
From: tleaver at synchronics dot com Assigned:
Status: Not a bug Package: Sockets related
PHP Version: 4.3.4 OS: Windows XP
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.
Block user comment
Status: Assign to:
Bug Type:
From: tleaver at synchronics dot com
New email:
PHP Version: OS:


 [2004-03-02 13:48 UTC] tleaver at synchronics dot com
We have a commercial PHP-based product, basically a web app which interfaces with our Counterpoint point of sale product, and is designed to run on wireless handheld devices.

Communications with Counterpoint is handled via an application server, which we communicate with from PHP via a socket connection.

Of the different types of messages we pass back and forth between PHP and the application server, is a transaction describing a complex item with multiple dimensions (size, color, etc).  When retreiving this large block of data from the socket using fread, we get unexpected data.

Each packet which is exchanged consists of a beginning 1 byte marker ("\x02") which denotes the beginning of a package, followed by a protocol version (internal designator), followed by 2 bytes indicating the length of the packet.  We then fread that number of bytes from the socket, followed by 12 bytes of additional data tacked onto the end of the information.

Certain communications are multi-packet, so the code loops until we either hit an feof condition or do not receive the expected beginning marker (which is an error).

Using PHP 4.3.1 and earlier, down to 4.1.1, the code works fine.  With PHP 4.3.2 and newer, including 4.3.5RC3, the code chokes on large packets.

That's as precise as I've been able to be to date.  We are not using a debug tool as of yet, so I can't be very precise.  The code necessary to reproduce the problem would require Counterpoint and our application server be installed, which isn't feasible.

Perhaps someone could look for changes in fread since 4.3.1 and see if there is a problem?


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2004-03-02 16:07 UTC]

fread() reads up to length bytes from the file pointer referenced by handle. Reading stops when length bytes have been read, EOF (end of file) is reached, or (for network streams) when a packet becomes available, whichever comes first. 

The length parameter for fread is a MAXIMUM length to be read, not a minimum or an exact.

If you're expecting a specific number of bytes, you should use a loop to repeatedly call fread() each itteration of which returns a new network packet.

Note also that this is a duplicate bug report.  The exact behavior you describe has been reported and documented on already.
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Wed Jun 03 13:01:25 2020 UTC