asked on

Problem with SSL 302 Redirect Using WordPress on MediaTemple

I have an SSL Cert installed on a MediaTemple hosting account. HTTPS functions properly when accessing a stand-alone file such as an image, but when requesting a page or URL controlled by a WordPress installation via HTTPS, the browser gets caught in an infinite loop of 302's. This occurs even on a fresh, vanilla install of WP.

Viewable at https://www.iamoriginone.com/press

https://www.iamoriginone.com/press
 
 
 
GET /press HTTP/1.1
 
Host: www.iamoriginone.com
 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
 
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
 
Accept-Language: en-us,en;q=0.5
 
Accept-Encoding: gzip,deflate
 
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
 
Keep-Alive: 300
 
Connection: keep-alive
 
Cookie: __utmb=226724613; __utmz=226724613.1195438852.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none); __utma=226724613.862624054.1195438852.1195438852.1195439009.2; PHPSESSID=b4b9a971fcb040cb256ed8f0cc37cff5; __utmc=226724613
 
 
 
HTTP/1.x 302 OK
 
Date: Mon, 19 Nov 2007 02:25:17 GMT
 
Server: Apache/2.0.54
 
X-Powered-By: PHP/5.2.2
 
Expires: Thu, 19 Nov 1981 08:52:00 GMT
 
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
 
Pragma: no-cache
 
X-Pingback: http://www.iamoriginone.com/xmlrpc.php
 
Location: https://www.iamoriginone.com/press
 
Vary: Accept-Encoding
 
Content-Encoding: gzip
 
Content-Length: 20
 
Keep-Alive: timeout=2, max=50
 
Connection: Keep-Alive
 
Content-Type: text/html; charset=UTF-8

Open in new window

stemwinder

ASKER

I was able to solve this problem myself. For any visitors experiencing the same problem:

The MediaTemple (though I doubt this is unique to MT) server's PHP variable 'HTTP_HOST' apparently has ':443' attached to the end of it when operating under HTTPS, even though this modification to the string is not visible otherwise (that is, there doesn't seem to be a redirection taking place). This addition to the URL creates a mismatch between what WordPress thinks the URL for the requested page should be (which is what could very well be entered into the browser's address bar), and what WordPress interprets as the requested URL (what is entered in the address bar), which it uses the 'HTTP_HOST' variable to build.

The solution is to remove the ':443' port string from the built URL. Add the following immediately below line 14 in wp-includes/canonical.php (WP 2.3+).

$requested_url = str_replace(':443', '', $requested_url);

Open in new window

ASKER CERTIFIED SOLUTION

EE_AutoDeleter

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial