[wp-trac] [WordPress Trac] #24646: fetch_feed() returns WP_Error with "A valid URL was not provided"

[WordPress Trac]

#24646: fetch_feed() returns WP_Error with "A valid URL was not provided"
--------------------------+--------------------
 Reporter:  husdaman      |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  3.5.3
Component:  Feeds         |     Version:  3.5.2
 Severity:  major         |  Resolution:
 Keywords:                |
--------------------------+--------------------

Comment (by nacin):

 Note that [24896] reverted [24482] for 3.6, which should alleviate any
 issues people were having in 3.6 but *not* in 3.5.2.

 To fix some issues in WordPress 3.5.2, I am currently toying with
 [attachment:24646.4.diff]. If it detects a host as local, it then does the
 following:
  * If multisite, it confirms the domain is *not* another site in the
 multisite install. If it is, then the host is considered "safe".
  * Uses wp_validate_redirect(), which implements an allowed_redirect_hosts
 filter, which is used in wp_safe_redirect(). If we are safe to publicly
 redirect to a page, we're also safe to send an HTTP request to it — so we
 let these through.
  * Adds a http_request_host_is_external filter. Hopefully the name is
 obscure and specific enough to not cause people to randomly whitelist
 everything using this method. In the future, we may wish to block
 "localhost" from being a safe host even *with* that filter. (If the site
 is running on "localhost", then it'll already be whitelisted.)

 That multisite query hits the `domain` index in `$wpdb->blogs` which means
 it is ridiculously fast. (rboren tried it on WP.com.) Which is why
 wp_is_large_network() isn't checked. This also only fires when we think it
 is a locally resolved domain, which on a well-configured server isn't
 actually the case.

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