[wp-trac] [WordPress Trac] #17251: Determine if any WP_HTTP transport can be used before making the request

[WordPress Trac]

#17251: Determine if any WP_HTTP transport can be used before making the request
-------------------------+-----------------------
 Reporter:  mdawaffe     |       Owner:  dd32
     Type:  enhancement  |      Status:  assigned
 Priority:  normal       |   Milestone:  3.2
Component:  HTTP         |     Version:  3.2
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |
-------------------------+-----------------------

Comment (by mdawaffe):

 Replying to [comment:2 sivel]:
 > This is just a thought, but what if we added the functionality for a
 fallback URL, or fallback protocol?  If the request can not be completed
 for the URL based on the tests, it can fallback to another URL or
 protocol.

 That wouldn't help here.  In the example above, the code needs to know
 what protocol can be used before signing the request.  Having WP_HTTP
 auto-fallback to a different protocol would either: A. send the same
 request to the new URL (which wouldn't work because the signature would be
 wrong) or B. require the plugin to sign both requests ahead of time (which
 is even worse than the situation we're in now).

 > Not that I am not open to new ideas, but it has come up several times
 that we should allow someone to be able to specify the transport they
 wanted to use, but it was generally dismissed, as that is not what the
 HTTP API was really meant for.

 It's a slight efficiency boost in this case, since the code will already
 have done the {{{::test()}}}s; they don't need to be run again.  With this
 use case, there's no change to how the WP_HTTP API is used.  The code
 isn't transport bigoted; it still lets the WP_HTTP API choose.

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