How does URL rewriting affect the $_GET parameter for PHP?
Say I have a URL like http://example.com/index.php?p=contact and I use $_GET['p'] to tell index.php to serve the contact page. If I use a rewrite rule that converts the URL to http://example.com/contact, will $_GET['p'] still work as expected?
If it does, could you elaborate on why it works? If not, what strategies could be used to solve the problem so that the page will work both with and without the rewrite?
I'd amend Grant's answer to "Yes, that will work mostly as expected."
Specifically, mod_rewrite's behavior with regards to existing query strings can be surprising. As an example, let's take the following rule, which converts the URL you supplied:
RewriteRule /contact /index.php?p=contact
This will correctly rewrite /contact to /index.php?p=contact and the page name will be accessible through $_GET['p']. However, if you use this technique with a script that uses parameters other than the page name, it gets slightly trickier. This rule also translates /contact?person=Joe to /index.php?p=contact. The person=Joe parameter disappears entirely! There are two ways to deal with this.
The simplest way is to use the [QSA] ("query string append") flag on your rule, which will place the original query string after the parameters supplied in the rule, translating /contact?person=Joe to /index.php?p=contact&person=Joe:
RewriteRule /contact /index.php?p=contact [QSA]
However, this makes it possible for your p= parameter to get overwritten. Visiting /contact?p=about will get rewritten to /index.php?p=contact&p=about, so $_GET['p'] will return "about" in your script, not "contact". To resolve this, use the QUERY_STRING variable instead:
RewriteRule /contact /index.php?%{QUERY_STRING}&p=contact
This guarantees that $_GET['p'] will always return "contact" when using this rule, regardless of whether your visitors are messing with your URLs. :-)
Yes, that will work as expected.
When rewriting an URL this is done by mod_rewrite -- the page retrieved in the end is still the "old" one, i.e. index.php?p=contact. In other words, the browser retrieves /contact. mod_rewrite then rewrites it to index.php?p=contact. The script, due to this, doesn't know that any rewriting happened -- it still gets called its "usual" way. Therefore such a rewrite will work. You might want to think of it as a rewriting proxy that requests a different page than the one the originating browser requested.
When the client requests http://example.com/contact, the server uses the rewrite rule to serve them http://example.com/index.php?p=contact instead. The client will not be able to see the rewritten URL and might not even be able to tell that it was rewritten. Requesting either URL as the client would give you the exact same page.
You rewrite URL from /contact to /index.php?p=contact, so yes, it'll work as expected.
Isn't it the case that modifying the headers after having rendered parts of the page can cause screw ups in php pages? How are you rewriting the URL? Maybe I misunderstand...
In your case it wouldn't work. mod_rewrite, after it finds a match and rewrites http://example.com/index.php?p=contact to http://example.com/contact, does an internal redirect. Even after the redirect, the new, redirected URI, can still be matched against a condition and further redirected.
In any case, incoming URIs aren't kept in memory, so not even Apache can reconstruct what the original URI was. PHP, by the time it's executed, also doesn't know the original URI. Hence, you loose your $_GET vars, as variables sent via GET are contained in the URL, which was, by now, transformed, and PHP populates the associative $_GET array by parsing incoming requests.
Offering support for both would be painstaking. If you have http://domain.com/segment1/segment2/segment3 you have to associate the segments with something meaningful. You'd strip your domain and explode on '/', and in your case you could say that the first segment requests the page, and from http://example.com/contact/ you can extract page = 'contact'
