[wp-trac] [WordPress Trac] #8622: HTTP API Fallover & non-blocking order doesnt appear to be working

[WordPress Trac]

#8622: HTTP API Fallover & non-blocking order doesnt appear to be working
------------------------------------------+-----------------------------
 Reporter:  DD32                          |       Owner:  jacobsantos
     Type:  defect (bug)                  |      Status:  reopened
 Priority:  normal                        |   Milestone:  Future Release
Component:  HTTP                          |     Version:  2.7
 Severity:  normal                        |  Resolution:
 Keywords:  has-patch tested 2nd-opinion  |
------------------------------------------+-----------------------------
Changes (by dd32):

 * keywords:  has-patch tested => has-patch tested 2nd-opinion


Comment:

 > That you've got a design problem doesn't come to your mind while your
 making that many words, right? (Not meant to sound rude, it's an actual
 question, not an attack, we need to deal with what we have so far)

 No, I agree with you there, It's a design problem for unit testing that
 you have to filter which transport to use, it however, is not a design
 problem for users of the API as they should never attempt to (or have a
 need to) use a transport directly.

 > That might just work, however, it depends on what you mean by failure.
 If there is a network issue preventing any of the transports from working,
 then you'll blacklist all of the transports from being used. There would
 have to be a way to check by what errors are considered the Transport not
 working.

 Which is exactly why we do not have fallover in core, it hasn't been there
 since day1 (even though it was intended) and there has been no need to add
 it.

 In most cases where a transport has failed, it's failed consistently (cURL
 and fsockopen) with the same error condition (DNS and no connectivity
 through that transport).

 To add fallover and enabled by default will increase the timeouts that
 users experience.
 Whilst a user should never be waiting on a HTTP request to complete in
 general, we do force that upon them in the Updaters/Installers as well as
 a few other locations related to media. To wait for all the transports (or
 a 2nd transport) to fail in many cases would lead to a bad user experience
 ("Its Slow!")

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/8622#comment:22>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software