[wp-trac] [WordPress Trac] #16158: 3.0.4 Upgrade failed on localhost testbed, successful on public site

[WordPress Trac]

#16158: 3.0.4 Upgrade failed on localhost testbed, successful on public site
--------------------------+------------------------------
 Reporter:  dturvene      |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  HTTP          |     Version:  3.0.1
 Severity:  normal        |  Resolution:
 Keywords:                |
--------------------------+------------------------------
Changes (by ocean90):

 * version:   => 3.0.1


Old description:

> 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?

New description:

 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?

--

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