[wp-trac] Re: [WordPress Trac] #7456: Timeout in WP_Http_Streams::request causes Fatal error abort

[WordPress Trac]

#7456: Timeout in WP_Http_Streams::request causes Fatal error abort
---------------------+------------------------------------------------------
 Reporter:  wet      |        Owner:  anonymous
     Type:  defect   |       Status:  reopened 
 Priority:  normal   |    Milestone:  2.7      
Component:  General  |      Version:           
 Severity:  normal   |   Resolution:           
 Keywords:           |  
---------------------+------------------------------------------------------
Changes (by wet):

  * status:  closed => reopened
  * resolution:  fixed =>

Comment:

 Doesn't work for me.

 Observed behaviour:

 # Takes approx. 60 seconds from browsing to http://example.com/wp-admin/
 to returning a blank screen.

 # Adding ''define('WP_DEBUG', true)'', I see


 {{{
 Warning: fopen(http://example.com/wp-cron.php?check=deadbeef)
 [function.fopen]: failed to open stream: [...] timeout [...]. in /www/wp-
 includes/http.php on line 672

 Fatal error: Maximum execution time of 60 seconds exceeded in /www/wp-
 includes/http.php on line 672
 }}}


 at http://example.com/wp-admin/. This is an expected (but imho undesired)
 behaviour, as the recent patch won't use $context as an input to fopen()
 and thus [http://trac.wordpress.org/changeset/8528 the previously
 established timeout] from $r['timeout] wouldn't come into effect.

 As you suspected, my Apache setup didn't include cURL. I subsequently
 loaded the cURL extension which remedied the deficiencies. So from my POV,
 WP_Http_Streams currently exhibits insufficient error handling for setups
 where a fallback from the higher preferred transports is required.

-- 
Ticket URL: <http://trac.wordpress.org/ticket/7456#comment:10>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software