[wp-trac] [WordPress Trac] #24646: fetch_feed() returns WP_Error with "A valid URL was not provided"
noreply at wordpress.org
Tue Jul 2 14:02:57 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:
Comment (by nacin):
Replying to [comment:26 joehoyle]:
> I recently ran into this (well, @matthue did!) with local development.
When local site "A" wants to send a request to local site "B", it will be
rejected, as that resolves to 127.0.0.1 via the hosts file. I think this
is the pattern a lot of developers use with vhosts etc, so might be worth
consideration if this goes into the next release from trunk.
The specific change from 3.5.2 to 3.6 has to do with .
Specifically, the HTTP API will by default reject all URLs it thinks is
unsafe, for all requests, not just the ones that explicitly pass an
argument as in . We're not sold on  for 3.6, and rather
wanted to "test flight" it to see what kind of bug reports we would get.
So thank you for helping!
I think we can safely allow traffic to 127.0.0.1 as long as the existing
site's domain also resolves to 127.0.0.1, and the port is standard (80,
443, or 8080, or if the port matches the site's port (which would work for
:8888 to :8888). We could also directly whitelist 8888 which is MAMP's
Unfortunately WP_DEBUG is not a great indicator of "production" versus
"development", so we couldn't just allow unsafe URLs for WP_DEBUG only.
> Another setup I run on a prod box is 2 sites on the same machine, where
they have "127.0.0.1 example.com" in the hosts file, which I believe again
would mean wp_http_validate_url would brake communication between the two
Yes — this definitely has the potential to break that setup as well, which
has been reported here. I am still not sure how to address this.
Without going into an incredible amount of detail, we're trying to prevent
server-side request forgery attacks. (Imagine me tricking your local
server trying to attack your router.) So locally-resolved requests are, in
general, untrusted. So we need to figure out how to make some of them
"work" without opening ourselves up to a vulnerability.
Even if we change the default (as in, reverting , which is very
likely at this time), we'll still need to allow locally-resolved requests
to work in certain cases. It appears there are two cases: When a server
directly resolves to itself or a nearby server in production via
/etc/hosts; and a similar development setup where domains are set to
I'm happy to discuss in deeper detail in private — nacin or security -at-
wordpress.org — especially if anyone has some interesting ideas.
Ticket URL: <http://core.trac.wordpress.org/ticket/24646#comment:27>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac