[wp-trac] [WordPress Trac] #18157: Warning message "Undefined property: WP_Http_Curl::$headers" on action=do-plugin-upgrade

[WordPress Trac]

#18157: Warning message "Undefined property: WP_Http_Curl::$headers"  on action=do-
plugin-upgrade
--------------------------+-------------------------------------
 Reporter:  chrisbliss18  |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  HTTP          |    Version:
 Severity:  normal        |   Keywords:  has-patch needs-testing
--------------------------+-------------------------------------
 After updating trunk today, I upgraded the plugins on my test site and saw
 the following warning message when I went to the plugins page:

 {{{
 PHP Notice:  Undefined property: WP_Http_Curl::$headers in wp-includes
 /class-http.php on line 1107, referer: wp-admin/update-core.php?action=do-
 plugin-upgrade
 }}}

 The warning went away when I refreshed the page, so this is not a
 persistent condition.

 It looks like the following is happening:

 1. An instance of the WP_Http_Curl has its request method called.
 1. The instance's headers instance variable is unset as part of the
 request method's cleanup.
 1. The instance's request method is called again, this time with a
 blocking arg of not true.
 1. Since blocking is not true, the WP_Http_Curl::stream_handlers instance
 method is not added as the CURLOPT_HEADERFUNCTION.
 1. Since stream_handlers does not fire, the WP_Http_Curl::headers instance
 variable isn't populated as the instance variable is still unset and could
 only be set/updated by the WP_Http_Curl::stream_handlers method.

 I would think that a line as simple as the following at the top of the
 request method could solve the problem:

 {{{
 $this->headers = ''
 }}}

 However, since I'm not fully aware of how everything needs to function, I
 suppose that this could cause issues.

 If this could work, I wonder if it would be better to simply set the
 variable to an empty string rather than unsetting it as I can also see a
 scenario where a warning would be created on subsequent requests
 regardless of the value of the blocking arg as the stream_headers method
 uses concat to set the headers variable which will cause a warning if the
 variable isn't set (which it won't be after each run).

 This approach is reflected in my attached patch. I'd definitely like it to
 be reviewed (preferably by dd32 as it looks like he wrote the code) before
 any consideration for being added.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/18157>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software