[wp-trac] [WordPress Trac] #37437: Requests_Cookie::parse() unable to parse WP_Http_Cookie object coming from WP_Http::request()

[WordPress Trac]

#37437: Requests_Cookie::parse() unable to parse WP_Http_Cookie object coming from
WP_Http::request()
--------------------------+-----------------------
 Reporter:  stephdau      |       Owner:  rmccue
     Type:  defect (bug)  |      Status:  assigned
 Priority:  high          |   Milestone:  4.6
Component:  HTTP API      |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+-----------------------

Comment (by stephdau):

 Also, the value of auth cookies shouldn't really hit that `parse()` method
 as stored in the object in the 1st place, since their format does not
 match. Hence my thoughts about "fixing" it higher (but that `explode()`
 call should be hardened anyways).

 If you look at the structure of the method's code, at the moment, there
 are more related things that have not yet been handled, like:
 {{{
 elseif (strpos($kvparts, '=') === false) {
 }}}
 or
 {{{
         else {
             list($name, $value) = explode('=', $kvparts, 2);
         }
 }}}
 which would fail if `$parts` is empty.

 Or `if (!empty($parts)) {` having no `else` clause, leading to `return new
 Requests_Cookie($name, $value, $attributes, array(), $reference_time);`
 being called without the expected values.

 So, one thing that would help me provide a patch would be decisions on how
 we would like the `parse()` method to gracefully fail when it does not
 receive the data it requires to provide a proper output. I have no
 directions to base such a decision myself in that method, at the moment,
 besides arbitrarily returning a `WP_Error` object, which other
 functions/methods are currently not written to handle higher up.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/37437#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform