Server variables apache provides to PHP

On different servers, I am getting different results in server vars

[jasimon9]

During the process of adding some rewrite rules, I am running into problem which might to be caused by different apache versions providing different values to PHP which are exposed to the PHP script via $_SERVER. Or it might be something else entirely.

One version is apache 2.2.4 running in a Windows XP VM, and the other is and apache 2.2.22 running on a Mac. Both are development systems.

I originally verified that after redirecting and rewriting, that the value of request which is stored in $_SERVER['REQUEST_URI'] would going to be what I expected: namely, the value of the original URL provided by the browser. And in fact on the apache 2.2.4 instance that is the case.

However, on the 2.2.22 instance, the value is the redirected URL. Naturally, this is has caused a lot of trouble!

I have carefully provided (nearly) identical rewrite rules and the identical PHP test script. So I am thinking it is neither the rules nor the code. I say "nearly" identical because the redirect rule includes the protocol and host on the redirect, and they are appropriate for each server, and thus differ.

I am writing this question in the hope that someone can shed light on the problem. That is, could it really be a different in the behavior of apache? Or is there some other setting that I am missing?

For both servers, the rewrite rules are set in httpd-vhosts.conf, not in .htaccess. And FollowSymLinks is set for both hosts.

My workaround for this behavior will be to add some PHP code to compensate. But I would like to know the root cause so a better solution can be applied.

Any guidance is appreciated.

[lucy24]

I know this answer will drive you stark staring bonkers, but it's important. Honest.

Can you provide a little more detail about what happens between
{beginning: user clicks on link or types in address}
and
{ending: server does its thing by, ahem, serving content}

I need to be absolutely convinced that you know the difference between a redirect and a rewrite. Yes, I realize you may have made it perfectly clear in earlier threads over the years. But the WebmasterWorld forums are indexed like mad, so you need to treat each thread as an island.

Even within Apache, REQUEST_URI and REQUEST_FILENAME can mean different things-- and it's the kind of difference that can rise up and bite you.

[jasimon9]

I appreciate your response, and it does not drive me bonkers. I reserve getting bonkers-driven for things other than people trying to help me.

Just an update. I have not had a chance to examine the details necessary to answer questions of lucy24. But I have made some progress in general and am reporting on that.

I am trying to get away from the Windows environment because it is too much out of sync with our main development and production environments. So debugging that becomes academic.

Part of the problem I have been having is that on our production, test, quality and "regular" development environment we have name-based vhosts. Plus SSL. But on the environments on my own workstations, for reasons not worth going into, I had port-based vhosts. This seems to cause problems with SSL when redirecting, as it becomes very confusing as to whether the connection should be SSL or not as the port-based SSL takes over from the port-based vhost.

This may or may not be a problem, but I am changing from port-based to name -based everywhere.

What happens to cause the confusion, is that after being redirected to the pretty url, which is in SSL, later site accesses lose the port. But that is not valid, so the url in the address bar has to be manually modified to have the port. It goes like this in the address bar:

[localhost:8080...] --> click
[localhost...] (note that the 8080 has disappeared probably due to the port-based SSL --> click
[localhost...] giving page not found error, until 8080 is manually put back into the url

Yet as stated, by going to entirely name-based vhosts, I am hoping to eliminate this issue. I have not gotten that far yet.