3.0.4 Upgrade failed on localhost testbed, successful on public site

[dturvene]

Running: 3.0.1, Ubuntu, Apache

I'm still looking at this but wanted to report it while I have a break.

I got the holiday notice to upgrade to 3.0.4. When I did an auto-upgrade on my local testbed (​http://localhost:9090/wp/wp-admin/update-core.php), WP reported that I have latest version. Plugin upgrades work fine. The auto upgrade was successful on my public sites. I have WP_DEBUG, etc. on for my local testbed and no errors were reported. I have upgraded my local testbed this way in the past, definitely for 3.0.1.

Below is a debug dump I hack in the WP_HTTP->request call coming from wp_version_check. I pasted the URL use into the browser bar it returned the correct information. Called from wordpress localhost, api.wordpress.com returns a HTML document with the <title>Page not found</title> and a bunch of info about wordpress.

[08-Jan-2011 20:42:48] URL='http://api.wordpress.org/core/version-check/1.5/?version=3.0.1&php=5.3.2-1ubuntu4.5&locale=en_US&mysql=5.0.83&local_package=&blogs=1&users=2&multisite_enabled=0'
[08-Jan-2011 20:42:48] r=array (
  'method' => 'GET',
  'timeout' => 3,
  'redirection' => 5,
  'httpversion' => '1.0',
  'user-agent' => 'WordPress/3.0.1; http://localhost:9090/wp/',
  'blocking' => true,
  'headers' => 
  array (
    'wp_install' => 'http://localhost:9090/wp/',
    'wp_blog' => 'http://localhost:9090/wp/',
    'Accept-Encoding' => 'deflate;q=1.0, compress;q=0.5',
  ),
  'cookies' => 
  array (
  ),
  'body' => NULL,
  'compress' => false,
  'decompress' => true,
  'sslverify' => true,
  'ssl' => false,
  'local' => false,
)

So two problems:

1) If the local site core check fails, it assumes what it is running is the most current. There is no indication that the core check failed. It seems like the "Page Not Found" page returned from api.wordpress.org should be displayed. See #16156, #16094 for similar issues.

2) What in the request is causing the HTTP get to fail? I think it must something in the header information. BUT, it USED to work. Is the server behaving differently?

[SergeyBiryukov]

Related: #16156

[dd32]

The problem might be the timeout, When running on slower connections, or those with higher latency, less reliability, etc, the timeout can sometimes be too short.

Try increasing it and see if that helps?

Other than that, as pointed out, the error messages for lack of connectivity and failures need to be overhauled.

[garyc40]

I don't think it was a timeout though. Based on what was reported, seems like a response code of 200 was returned.

To dturvene: Could you also dump the request URL inside wp_version_check()?

[garyc40]

validate content-type of response

[garyc40]

Just in case the response code is 200, and a HTML response body is returned (due to some sort of error or something), we should probably validate the response body as well.

Right now the only way I can think of is checking content-type (see patch).

Perhaps switch API to returning json in API v1.6?

[nacin]

Or serialized PHP.

We need to validate this somehow. I got the starbucks proxy page stuffed into a transient last week.

[dd32]

Ah yes, I misread the ticket.. Validation needs to happen here, switching to a Serialized PHP return seems to be the most obvious solution, and it'll fit in with the rest of the API's default return types

[dturvene]

The upgrade seems to work from ​http://localhost:9090 now. Sorry for the false alarm.

Just to document the symptoms from last night:

Response code is 404 and the wordpress.com "Sorry, no posts match your criteria" page is returned in the body.

Here's the URL I dumped directly from the WP_Http::request call:

​http://api.wordpress.org/core/version-check/1.5/?version=3.0.1&php=5.3.2-1ubuntu4.5&locale=en_US&mysql=5.0.83&local_package=&blogs=1&users=2&multisite_enabled=0

Additionally,

Also, I noticed that if get_core_updates fails then list_core_update isn't called and there is a hole on the update screen the text from list_core_update should be. So, at least, that's an indication that version retrieval from wordpress.org did not work for some reason.

[dd32]

Ah yes, I misread the ticket.. Validation needs to happen here, switching to a Serialized PHP return seems to be the most obvious solution, and it'll fit in with the rest of the API's default return types

The 1.6 version of the Core Update check API returns serialized data. The other items are fixed/worksforme