ID: 41770 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Feedback Bug Type: Streams related Operating System: Linux PHP Version: 5.2.3 Assigned To: iliaa New Comment:
I am unable to reproduce the bug with 4 different HTTPS hosts and the provided code. Do you have a particular URL/host that can be used to reproduce the described issue. Previous Comments: ------------------------------------------------------------------------ [2007-07-02 16:50:24] [EMAIL PROTECTED] iliaa: All you did is make the warning not appear with that commit. You didn't fix the underlying issue with the connection. It still closes the connection and now it will just mysteriously start failing rather then giving a warning about why it's failing. I would revert your commit and not mark this as fixed. ------------------------------------------------------------------------ [2007-07-02 16:42:17] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. ------------------------------------------------------------------------ [2007-06-21 19:35:37] [EMAIL PROTECTED] It's some streams issue, reclassified as such. Too bad we're out of streams developers right now. :) ------------------------------------------------------------------------ [2007-06-21 19:22:17] [EMAIL PROTECTED] Bug #34668 as well. ------------------------------------------------------------------------ [2007-06-21 19:21:43] [EMAIL PROTECTED] Description: ------------ Essentially this bug is a mash up of #39283, #35758, #41021, #39039 and possibly others. Essentially the code I'm using looks like: $fd = fsockopen("ssl://myhost, myport, $error, $timeout); $data = fread($fd, 8192); But you can create the same error using: - SoapClient to fetch a WSDL file. - file_get_contents() - file() The backend can be an Apache server or a custom app internally that serves SSL encrypted data. It doesn't matter. If the transmitted data is smaller then the $length passed to fread, everything works successfully. I chose 8192 in my example because file(), file_get_contents() and SoapClient all use 8192 internally based on how the work. Now if the actual data being transmitted is 10000 for example, you will receive the first block of data fine. Then the next time you call fread(), or in the case of SoapClient, file_get_contents(), file() they will do this internally. You will get: "SSL: fatal protocol error" printed out and any subsequent action on the file descriptor will result in an OpenSSL error saying the socket has already been shutdown, as per line 116 (current CVS) of ext/openssl/xp_ssl.c Now you can create this situation with 2048 of data as well. Just call fread($fd, 1024); or fread($fd, 2000); and it will trigger. Basically the $length has to be less then your total amount of data and it will occur. A lot of the previous bugs PHP developer mention IIS while users mention Apache. I have not tested IIS. I have only tested Apache and a custom app which serves data over SSL. I have tested the output of Apache with wget and the custom app with openssl s_client and both work properly. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=41770&edit=1
