[wp-trac] [WordPress Trac] #33055: Support Parallel HTTP Requests in WP_Http, et al

[WordPress Trac]

#33055: Support Parallel HTTP Requests in WP_Http, et al
----------------------------+--------------------------
 Reporter:  wonderboymusic  |       Owner:  rmccue
     Type:  task (blessed)  |      Status:  assigned
 Priority:  high            |   Milestone:  4.6
Component:  HTTP API        |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  needs-patch     |     Focuses:  performance
----------------------------+--------------------------

Comment (by rmccue):

 Replying to [comment:40 kovshenin]:
 > Unfortunately this broke cron spawning across wordpress.org because of
 the 10 milliseconds timeout, which used to be rounded up to 1 second prior
 to `CURLOPT_TIMEOUT_MS`. Ten milliseconds is often not enough to perform a
 DNS request, or a TLS handshake. If we still want to support milliseconds,
 we should increase the timeout when spawning the WordPress cron.

 This definitely sounds like a misuse of the HTTP API; if you're specifying
 a 10ms timeout, then you should get that. Expecting it to round up to a
 second is using undefined behaviour. Let's fix it in the other tickets
 though. :)

 Replying to [comment:42 aaroncampbell]:
 > The issue is that PHP's is_array() returns false for objects that
 implement ArrayAccess. Obviously the old return was a real array, so it
 worked.

 Technically speaking, yeah, it's a BC break there. Annoyingly,
 `is_array()` doesn't check `ArrayAccess` :'(

 However, the HTTP API only ever returned either a WP_Error or an array
 (now an error or an array-like object), so there's no real need to check
 the type at all. I get the idea of defensively programming here, but it
 has the result of making the code brittle to changes.

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