top.location redirect issue

Topics: Developer Forum
Sep 20, 2011 at 11:13 PM
Edited Sep 20, 2011 at 11:13 PM


I am using the following:

  RewriteCond %{HTTP_HOST}   ^([^\.]+)\.([^\.]+)\.([^\.]+)\.([^\.]+)\.com$
  ProxyPass ^/(.*)$   http://*1.*2:8880/$1
  ProxyPassReverse   /         http://*1.*2.*3.*4:8880/

Which works great except for one thing. The remote page has the following code:

  <body onLoad=";top.location='/login.php3';"></body>

This has the undesired result of redirecting the client browser directly to http://*1.*2:8880/$1  which then bypasses the whole point.

I have no control over the code on the remote server. Is there a way to rewrite this redirect?

Thanks again!!



Sep 21, 2011 at 3:14 PM

I don't know.  It seems to me your code on the remote server is not rewrite-friendly.  There is no reliable way to use a URL rewriting agent to cover all cases when URLs are hardcoded into the text of the response. ProxyPassReverse works for a links, but does not work for random javascript that redirects. 

One way to handle it is to insert rules that catch requests from such hardcoded URLs.  You'd have to sue Fiddler2 (or similar tool) to see exactly what is being requested by the browser when it calls that top.location thing. Then insert a rule that handles that edge case. Or, convince the people that own the code to not hardcode URLs like that.

Good luck.

ps: In your prior message you said you were using #{HTTP_HOST} but in this message it clearly shows %{HTTP_HOST}.  What gives?

Sep 24, 2011 at 6:39 AM


I've been playing with Fiddler 2and one of the entries looks suspect.  I have pasted the raw data below and you can see that the Location header has not been rewritten. I'm not sure if this is the reason, but it is suspect.

I have also saved all of the sessions for this issue in the following Fiddler2 export if it helps:

Your help is greatly appreciated.

Also. To answer your PS. That was a typo on my part. I meant to write %. 

Thanks again!


HTTP/1.1 303 See Other

Date: Sat, 24 Sep 2011 05:14:21 GMT

Date: Sat, 24 Sep 2011 05:14:17 GMT

Server: Microsoft-IIS/6.0

X-Powered-By: ASP.NET

Cache-Control: post-check=0, pre-check=0,no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Pragma: no-cache

Content-Type: text/html; charset=utf-8

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Last-Modified: Sat, 24 Sep 2011 05:14:17 GMT



X-UA-Compatible: IE=EmulateIE7

Connection: close

Content-Length: 0

Via: 1.1 (IIRF v2.1)


Sep 25, 2011 at 2:00 PM

What do you mean by "looks suspect"?   Is that URL live, or not?  If you request    , what do you get?   you also didn't say what

I looked in the .saz file you enclosed; I found a request, #008, for that url.

It gets a 200 (OK) response. So it doesn't look "suspect" to me, based on that.

There is a 404 response in that set.
It is for

I suspect your IIRF configuration has rewritten it incorrectly , or something, which prevents it from being satisfied.

But listen, I'm not going to comb through your plesk logs to fix this. I don't know plesk, or I might have better suggestions to offer. But I do have a suggestion: You'll need to do better diagnosis on your end. Fiddler can help you see 404s, very easily. They are highlighted in red. When you see a 404 in the Fiddler log, then you know that URL is worth investigating.

When you see that, go to the IIRF log and determine if it has been rewritten, redirected, proxied, or whatever.  At that point you can figure out if and how you need to change the IIRF.ini file to handle that URL.

If you get to a point where you cannot understand what is happening in the IIRF log, or if you see an error in the IIRF log, then I can help with that. Send me that. I'm not going to be helpful if you send me plesk logs. You can look through those, better than I can.

Good luck!

Sep 25, 2011 at 8:48 PM

Hi Cheeso,

Thank you very much for your response and time with me on this. Please know that I have almost ZERO experience with Proxies or Fiddler, so my "assumptions" were only based on guesswork at this point.  I wasn't even sure on what was a request and what was a response, which threw off my assumption.

I should also point out that the Plesk install I am trying to reach is not under my control, hence my need for the Proxy. What this means is that I have no control over the code and cannot view the Plesk logs.

Thank you for going above and beyond with me thus far. I will attempt to track down those 404s.




Sep 26, 2011 at 6:14 AM

I figured it was something like that . . . The 404 - I saw only one, but I didn't investigate exhaustively - is definitely a concern. Check the IIRF logs to see if it is being rewritten or proxied correctly or not.


Sep 27, 2011 at 10:58 AM

Well, after investigating futher I can say that there is a hard coded Javascript redirect in the code that sends the client to the original (un-proxied) url.

Unless there is any way to rewrite the html code as it is being delivered to the client I am out of options.

Sep 28, 2011 at 7:23 AM
Edited Sep 28, 2011 at 7:30 AM


I wanted to report back that I got this working in apache and perhaps in the future you could modify your module to accomodate as I would much prefer to use IIRF than run apache for 1 proxy.

This was the apache proxy line of code that fixed the header location redirect:
  Header edit Location ^http(.*)8880 ""

Here is my complete apache code for reference.

 RewriteCond %{HTTP_HOST} ^(.*)\.(.*)\.pleskpx\. [NC]
 Header edit Location ^http(.*)8880 ""
 RewriteRule ^/(.*) http://%1.%2:8880/$1 [P]
 ProxyPassReverse / http://%1.%2:8880/$1

Your module is great, and if you could add the ability to edit the Response header I would move back to it in a heartbeat.


Oct 2, 2011 at 10:54 PM

Thanks for your compliments.

I'm glad to make appropriate modifications to make IIRF work better but I don't understand the situation here well enough to know just what to modify.

I'll look into the Apache directive to see what it does, and how that might be accomplished in IIRF.  That may involve a new directive. I don't know, will require some research on my part.



Oct 2, 2011 at 10:55 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Nov 2, 2011 at 9:07 PM

Header edit Location is a thing that is supported by mod_headers, an Apache-specific module. You can do the same thing in IIRF with RewriteHeader.

Check the IIRF documentation.