The RewriteBase is designed to UNDO a mod_alias redirection before processing mod_rewrite directives. Where are your Redirects? Get rid of silly code that is unnecessary!
Where do you set REDIRECT_STATUS? Okay, if it works, don’t fix it but if you don’t show all your .htaccess, I can’t judge. However, I know that the two methods in the tutorial work perfectly to prevent looping and the second one was designed to do exactly that (by the Apache team, i.e., preferred).
I do not know whether your code (as displayed) has any chance of working but you’re saved by Apache 2’s limit of 10 loops before it will terminate processing mod_rewrite code (Apache 1 would have to be restarted by the sysadmin!). In other words, learn the correct way and use it to avoid problems. I worked out the first (“marker”) solution before having the {IS_SUBREQ} pointed out to me so I’m NOT throwing rocks, just pointing out something learned from experience.
If you want to show one URI but present another to the visitor, mod_rewrite is a GREAT tool!
I’ve got to assume that user is a variable ($gUserUrl) so that makes things a little difficult, however, disregarding any/all other mod_rewrite you’re using:
What I would like is for the user to still see the following http://www.learnintouch.com/user/login/ when he types in a wrong password or does any mistake in the form.
Okay, you’re NOT listening (reading)! Having an optional trailing / is a common problem as the visitor’s browser does not know which directory level it’s in. That doesn’t matter if ALL your supporting files are linked with absolute links but they’re usually not. Try with both the / and non-/ versions of your URI to see what I mean.
Wrong password SHOULD cause the script to reinitialize to the pseudo link, not to the actual link!
Both the form and the error handler should send to the pseudo link, too.
Not boring … helping members is why I’ve been here for so many years.
I would like to do TWO different url rewritings. One: Typing in the user/login actually serves the content at the url engine/modules/user/login.php Two: Typing in the url engine/modules/user/login.php redirects to the url user/login so as to never display the real url (too techie, no need to tell its php, no beautiful enough, etc…)
I don’t have .htaccess files in my directories. I only have one url_rewrite.conf file that I include from my httpd.conf file.
I attached the full url_rewrite.conf file to the post.
The part that interested me in your tutorial was this one:
Redirect TO New Format
I have fielded questions where someone wanted to redirect their real URIs to
extensionless URIs so search engines would update to their new, extensionless format?
Okay, Apache can do that but it can not serve scripts in the new format (they have to be
redirected back to the real link!). Have I got your head spinning?
I do NOT recommend this (unless you’re on a dedicated server with low volume) as it
requires additional processing by Apache.
The key to this is the No Subrequest flag which will prevent redirection if a request has
already been redirected.
Aw, $#!7! Silly error (on my part). Without R=301 (or external absolute redirection), the redirected URL will not be seen. I’m also not fond of the order so I’ve altered that, too.
Do you have any mod_alias (Redirect family) statements in your .htaccess file? If you’re not sure, please post your current .htaccess file (wrapped in a [noparse]
No Apache configuration files at all? OMG! Are you at least using an Apache browser? If not, mod_rewrite gets emulated but that’s not always successful.
A search of Apache.org left me without anything but the above to report. However, a web-wide search brought several options as this seems to be a common problem:
Do NOT redirect the form’s action, i.e. send it to the correct file. For you, that’s a problem as you don’t want the real address to be viewed.
I’ll also add “do not use an absolute (external) redirection and do not create a query string.” The code I provided in post 34 above followed those rules (what happened to that code?). I suspect that the point of contention Apache has is that it usually only has to deal with POST or GET (okay, and COOKIE) within the REQUEST array.
Please let us know if any of the above work for you.