php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #48472 fgets/fread behaviour on socket timeout undocumented
Submitted: 2009-06-04 16:27 UTC Modified: 2009-11-16 13:37 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: nick dot telford at gmail dot com Assigned:
Status: Not a bug Package: Documentation problem
PHP Version: Irrelevant OS: CentOS 5.3
Private report: No CVE-ID: None
 [2009-06-04 16:27 UTC] nick dot telford at gmail dot com
Description:
------------
When using stream_set_timeout() to set a timeout on a stream it is documented that you need to check stream_get_meta_data() to see if the stream timed out. However, the behaviour of fgets/fread (in blocking mode) when the socket times out is not documented.

At first, I assumed that the time out would be considered a "failure", which is documented in both fread and fgets as returning FALSE.

However, after testing, it appears that both methods return an empty string when the socket times out. This is fine, because you can check to see if this was because of an EOF (using feof) or a timeout (stream_get_meta_data) after the method has returned.

The only problem here is a lack of descriptive documentation. The behaviour of blocking read functions when the stream times out needs to be documented as this is a common scenario when working with socket streams.

Regards,

Nicholas Telford


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-06-04 16:28 UTC] nick dot telford at gmail dot com
Forgot to mention. Bug #31897 seems related but slightly different - as it was fixed and closed when the docs about having to check stream_get_meta_data() was added to stream_set_timeout().
 [2009-11-16 13:37 UTC] vrana@php.net
Already documented: "When the stream times out, ... no error/warning is generated."
 
PHP Copyright © 2001-2026 The PHP Group
All rights reserved.
Last updated: Tue Jun 16 14:00:01 2026 UTC