[wp-trac] [WordPress Trac] #24646: fetch_feed() returns WP_Error with "A valid URL was not provided"
WordPress Trac
noreply at wordpress.org
Tue Jul 30 20:43:45 UTC 2013
#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
More information about the wp-trac
mailing list