[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  |
------------------------------+-----------------------------

Comment (by jacobsantos):

 Replying to [comment:19 dd32]:
 > > As for unit testing,
 >
 > Very simple to do. Filter the ::test() methods to select which transport
 you wish to test, test, remove filters, rinse repeat.
 [[BR]]

 If you are writing your tests this way, then you are doing functional
 testing. If you aren't unit testing the individual transports as well,
 then you are doing it wrong.

 [[BR]]

 Replying to [comment:19 dd32]:
 > My suggestion here is to push the changes needed through #16870,
 specifically, when a transport fails, progressivly mark it as unusable.
 [[BR]]
 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.

 Also, provided that the first transport should normally almost always
 work, you'd only ever be using the first transport. The failure might be
 network related and in which case the next transport might be unaffected
 by it. If you wish, you may fall back to two transports either fsockopen
 or streams with fsockopen as the preferred alternative if available.

 [[BR]]

 Replying to [comment:19 dd32]:
 > The alternative is to adding an extra parameter similar to the block of
 code [http://core.trac.wordpress.org/attachment/ticket/8622/8622.4.diff
 starting line 206 in this patch], which would be purely for a plugins
 usage.
 >
 > In core we're striving for a HTTP API which just works, plugin authors
 shouldn't have to do anything more than request it, and handle an error
 condition being returned, but at the same time, it shouldn't cause
 unnecessary slowdowns for the user, failing over to the next transport
 over and over on a plugin's request should not be possible.
 [[BR]]

 Failing when the first transport fails and then conditionally preventing
 that transport from being used as opposed just dropping to the next
 available transport. I don't know, perhaps both might be better. I would
 say that if you are doing an HTTP request that is nonblocking, that
 performance and time doesn't really matter and what you want is the
 request to work regardless of how long it takes.

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