• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1916
  • Last Modified:

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

0
stemwinder
Asked:
stemwinder
1 Solution
 
stemwinderAuthor Commented:
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

0
 
EE_AutoDeleterCommented:
tkeyan,
Because you have presented a solution to your own problem which may be helpful to future searches, this question is now PAQed and your points have been refunded.

EE_AutoDeleter
0

Featured Post

What is SQL Server and how does it work?

The purpose of this paper is to provide you background on SQL Server. It’s your self-study guide for learning fundamentals. It includes both the history of SQL and its technical basics. Concepts and definitions will form the solid foundation of your future DBA expertise.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now