Do a redirect while masking the final URL

[moroandrea]

Apologies if this may sounds like a silly question, but I was wondering whether it would be possible to create a redirect from page A to B, but mask B URL to something different.

I have been able to do the redirect, but if I then attempt to a URL rewrite, it seems the condition doesn't match anymore, or perhaps I believe I ended up in a redirect loop (thought I applied a filter to exclude the redirect from the initial bit).

Any help is appreciated.
Thanks

[Dideved]

> I have been able to do the redirect, but if I then attempt
> to a URL rewrite, it seems the condition doesn't match
> anymore

No one will be able to help you spot the problem in your code unless you show your code.

[moroandrea]

Yeah, sorry

RewriteEngine on

RewriteRule / stop-account.html [L]

#urls to exclude
RewriteCond %{REQUEST_URI} !/stop-account.html$

RewriteCond %{HTTP_HOST} ^example.com$ [OR]
RewriteCond %{HTTP_HOST} ^www.example.com$

RewriteRule ^.*$ http://www.example.com/stop-account.html [R=302,L]

[edited by: phranque at 9:47 pm (utc) on May 21, 2013]
[edit reason] please use example.com to prevent linking example urls [/edit]

[lucy24]

RewriteCond %{HTTP_HOST} ^example.com$ [OR]
RewriteCond %{HTTP_HOST} ^www.example.com$

Do you have multiple domains passing through the same htaccess? Or subdomains that you want to omit from the redirect?
If no to both, the condition isn't necessary at all.
If no to the second (yes multiple domains, no subdomains), both conditions can be collapsed to
example\.com
without anchors-- but WITH escaped literal period. (In this situation, the chances of the . representing anything else are pretty minute. But stay with the habit.)

Did you notice that when you put up the post, your Rule target became unreadable? That's because you didn't use example.com the way the Forums keep telling you to. It's a universal rule at WebmasterWorld, but it goes double in Apache because we need to see the exact text of the rule.

Usually people in Apache have to be advised to leave a blank line after each rule. Here I've got the opposite advice: Don't leave any blank lines within a ruleset (conditions plus rule). This is for your own benefit, not Apache's; blank lines don't mean anything, but they let you see where one rule stops and another one starts.

RewriteRule / stop-account.html [L]

Is this happening within htaccess? In htaccess-- also in <Directory> sections in the config file-- an URL never begins with a directory slash. So an un-anchored slash in a RewriteRule means anything in a subdirectory. The rule will never apply to top-level files, including the front page. But it will apply to all inner files, regardless of format. Since the target is an html file without query, I'm pretty sure that isn't what you want to do. Constrain the rule to requests for pages (final / or .html).

RewriteRule ^.*$ ...

Here, on the other hand, the anchors are unnecessary because you're not capturing and you're not matching specific text in a specified location. They won't prevent the rule from working, but why clutter up the code?

Why is it 302 rather than 301?

Finally and most important:

Any rules that create a redirect (flag [R] or [R=301]) need to go before rules that create a rewrite alone (what you call "masking").

[Dideved]

First let me see if I understand your goal. Based on your current code, it looks like you're trying to do:

If user requests the root, then internal rewrite to stop-account. If user requests any other URL, then external redirect to stop-account.

Is that right? It sounds unusual to me, so I just wanted to double check.

[moroandrea]

Hi Lucy24

thanks for your answer and all the details. It was a fault of mine as I stick the code straight into the quick reply without thinking to the formatting at all.
Apologies for this.

So to recap what you said. The first two lines should be transformed into

RewriteCond %{HTTP_HOST} example\.com$

That's fine.

I still however need to sort out the second problem. I want to mask the page stop-account.html and let it appearing as index.html or just the root of the site.

Regrettably, adding something like this

RewriteRule ^index.html$ http://www.domain.com/stop-account.html [L]

enter into a loop.


@Diveded, your understanding is correct.

[Dideved]

@Diveded, your understanding is correct.

OK. Unusual, but OK. In that case, I think I see two issues, and an opportunity to simplify.

RewriteRule / stop-account.html [L] 

This is issue #1. Lucy mentioned this too. If this rewrite is in a directory context, such as an htaccess file, then there will never be a leading slash. Plus, without start- and end-of-string anchors, this will match any string that has a slash in it somewhere.

RewriteCond %{REQUEST_URI} !/stop-account.html$ 

This is issue #2. If there has been an internal rewrite to stop-account.html, then it won't be reflected in the request URI. You'll instead need to check the current -- and possibly rewritten -- path.

RewriteCond %{HTTP_HOST} ^example.com$ [OR] 
RewriteCond %{HTTP_HOST} ^www.example.com$ 

And this is an opportunity to simply. Lucy called this out as well. It isn't obvious why you need either of these lines at all.

All things considered, I would probably write it this way:

RewriteEngine On

# Rewrite root requests to stop-account.html
# (Note that if there's a directory index in this path, such as index.html,
# then mod_dir will send that response before any of these rewrite rules get the chance to run.)
RewriteRule ^$ stop-account.html

# Redirect all other requests to stop-account.html
# (unless the request is for stop-account.html itself)
RewriteCond $1 !=stop-account.html
RewriteRule (.*) /stop-account.html [R,L]

[lucy24]

If there has been an internal rewrite to stop-account.html, then it won't be reflected in the request URI.

You're confusing REQUEST_URI with THE_REQUEST. Although the names are similar, functionally they're very different. THE_REQUEST looks at what the User-Agent itself originally asked for. But REQUEST_URI means "whatever file you're currently looking at, whether it was an explicit request, the result of a rewrite, or even a subrequest".

moroandrea, you didn't say why you've chosen a temporary redirect. Usually a 302 means "I'm here for now, but later on I'll be back at the old URL so don't index (or link to) this new one". Most of the time, the "target" of a rewrite has the form

... http://www.example.com/more-stuff-here [R=301,L]

To constrain any RewriteRule to requests for pages, the basic format for the "pattern" is

(^|\.html|/)$

where ".html" should be replaced with whatever extension(s) your site uses. That's visible URLs, not physical filenames. If the target has the same extension as a real URL, you are correct that you need to include a RewriteCond excluding the REQUEST_URI to avoid an infinite loop.

[moroandrea]

Hi Lucy,

I added a 302 just to avoid the site loosing the indexation, at least during the first period until the bill will sorted out from customer.
If they will keep not paying I will stick on a 503 and I won't bother any more about the wealth of their site.


I need to include a RewriteCond excluding the REQUEST_URI to avoid an infinite loop.

So should I do something like this at the begging of the .htaccess to "mask" the URL?

RewriteCond %{REQUEST_URI} !^stop-account.html$
RewriteRule ^$ stop-account.html [L]

Should I bother about the fact that my directory still include a file names index.html?

[Dideved]

You're confusing REQUEST_URI with THE_REQUEST. Although the names are similar, functionally they're very different. THE_REQUEST looks at what the User-Agent itself originally asked for. But REQUEST_URI means "whatever file you're currently looking at, whether it was an explicit request, the result of a rewrite, or even a subrequest".

Nope, I had it right. REQUEST_URI is the path component of THE_REQUEST. An examination of Apache's logs shows this is the case.

Given the htaccess:

RewriteRule / stop-account.html

RewriteCond %{REQUEST_URI} !/stop-account.html$
RewriteRule ^.*$ /stop-account.html [R=302,L]

And given a request for:

/foo/bar

Here's what the logs show (the important line is bolded):

strip per-dir prefix: C:/Apache24/htdocs/foo/bar -> foo/bar
applying pattern '/' to uri 'foo/bar'
rewrite 'foo/bar' -> 'stop-account.html'
add per-dir prefix: stop-account.html -> C:/Apache24/htdocs/stop-account.html
strip per-dir prefix: C:/Apache24/htdocs/stop-account.html -> stop-account.html
applying pattern '^.*$' to uri 'stop-account.html'
RewriteCond: input='/foo/bar' pattern='!/stop-account.html$' => matched
rewrite 'stop-account.html' -> '/stop-account.html'
explicitly forcing redirect with [localhost...]

Notice that even though there had been a rewrite to stop-account.html, the value of REQUEST_URI was still /foo/bar.

EDIT: I have to amend this, because it seems we were both partly right. REQUEST_URI will indeed change for sub-requests, but it will not change during a rewrite phase.

[Dideved]

> I need to include a RewriteCond excluding the REQUEST_URI to
> avoid an infinite loop.

In case you're interested, I had tested the htaccess I showed before posting. It has all the behavior you were trying to achieve, and no loops.

> Should I bother about the fact that my directory still
> include a file names index.html?

Yes, that's going to be a problem. I mentioned this earlier too, but mod_dir will return a directory index response before any rewrite rules get the chance to even run. If you want the root path to rewrite to stop-account.html, then you'll either have to delete index.html or turn off the directory index.

[lucy24]

mod_dir will return a directory index response before any rewrite rules get the chance to even run

This depends on your server configuration. Within my personal experience-- same site, same host, probably same overall apache version-- mod_dir has done its thing both before and after mod_rewrite.

[Dideved]

This depends on your server configuration. Within my personal experience-- same site, same host, probably same overall apache version-- mod_dir has done its thing both before and after mod_rewrite.

Do you recall what that configuration is? How do you get mod_dir to not run until after a rewrite?

[lucy24]

How do you get mod_dir to not run until after a rewrite?

How do you get it to run before a rewrite?

:: detour to re-check this week's configuration ::

Request for directory
+ rule constrained to .html
=
rule WORKS if configured as an internal rewrite only [L]
rule DOES NOT work if configured as an external redirect [R=301,L]

I do not pretend to understand this. I'm just reporting results.

While I was at it, I re-checked earlier experiences with %{REQUEST_URI}. A rule such as

RewriteRule \.html /hoosegow/pagenew.html [L]

will lead to an infinite internal-redirect loop (500 error) unless there is a preceding RewriteCond
RewriteCond %{REQUEST_URI} !pagenew

It refuses even to display the 500 page, which should be outside the loop.

Both of these points are the same on test site (live) and MAMP (local). Both are 2.2 but are otherwise not identical. Both rules are in root-level htaccess. When I tried it on MAMP, the error log promptly ballooned to a jaw-dropping 22 megabytes-- and that's at the default logging level.

mod_rewrite tends to be one of the very first mods to execute.

[moroandrea]

I am definitely not so much in deep like you are in apache rewriting rule, but guys thank you both for sharing all your knowledge.
At least I picked up some extra bits.

[moroandrea]

However, I am still not able to achieve the final "masking" regardless I removed the index.html file from the root.

Stop-account.html keep featuring in the address bar.

[Dideved]

> How do you get it to run before a rewrite?

For example -- straight from this discussion -- if the htaccess is:

RewriteEngine On

RewriteRule ^$ stop-account.html

If mod_rewrite executes first, then the response would be stop-account.html. But if mod_dir executes first, then the response would be index.html. And the result is index.html. Do you get something different?

[Dideved]

Request for directory
+ rule constrained to .html
=
rule WORKS if configured as an internal rewrite only [L]
rule DOES NOT work if configured as an external redirect [R=301,L]

You didn't give me any code to repeat your test, so I tried this:

RewriteRule ^index\.html$ stop-account.html

And when I request the root, this does indeed end up on stop-account. The logs reveal why:

[initial] strip per-dir prefix: C:/Apache24/htdocs/ ->
[initial] applying pattern '^index\\.html$' to uri ''
[initial] pass through C:/Apache24/htdocs/
[subreq] strip per-dir prefix: C:/Apache24/htdocs/index.html -> index.html
[subreq] applying pattern '^index\\.html$' to uri 'index.html'
[subreq] rewrite 'index.html' -> 'stop-account.html'
[subreq] add per-dir prefix: stop-account.html -> C:/Apache24/htdocs/stop-account.html
[subreq] strip document_root prefix: C:/Apache24/htdocs/stop-account.html -> /stop-account.html
[subreq] internal redirect with /stop-account.html [INTERNAL REDIRECT]
[initial/redir#1] strip per-dir prefix: C:/Apache24/htdocs/stop-account.html -> stop-account.html
[initial/redir#1] applying pattern '^index\\.html$' to uri 'stop-account.html'
[initial/redir#1] pass through C:/Apache24/htdocs/stop-account.html

This seems to be another case where we're both partly right. Based on this test and the test one post up, I think we can conclude that mod_dir executes before mod_rewrite. But, mod_dir results in a sub-request, which gives mod_rewrite a chance to rewrite index.html to something else.

[lucy24]

Do you get something different?

As noted above, it depends whether the RewriteRule-- the identical rule, in the identical location-- is configured as a redirect or a rewrite. This seems to mean that even though they are the same rule in the same module, the redirect "sees" the URL while the rewrite "sees" the underlying file.

But either way, the Condition is required.

---

Whoops! Forgot about you there, andrea. If I were going at this from scratch, starting from:

"I want to temporarily redirect all requests for a particular domain to a specific page on that same domain"

that would be

RewriteCond %{REQUEST_URI} !newpage
RewriteCond %{HTTP_HOST} example\.com
RewriteRule .* http://www.example.com/newpage.html [R,L]

The default redirect is 302, so you don't need to spell it out. In fact the mere act of giving the full protocol-plus-domain will turn any rewrite into a redirect, so you're now in belt-and-suspenders territory if you really do want only a 302.

But wait!

You're doing the whole thing backward. First you redirect to the URL you want. Then you fetch content from wherever it really lives. But if your content lives offsite, why even bother with the redirect? Why don't you simply show the content at whatever URL the user asked for? Matter of fact, if you're trying to be nasty that would work even better-- and will play havoc with site indexing as you suddenly get Duplicate Content up the wazoo. This may or may not be a concern. If you're trying to minimize damage, a temporary redirect is the way to go.

The important question is where the "stop-account" content physically lives. Is it within the same directory as example.com? Or is it a single master page that lives elsewhere on your server? This will make the difference between a vanilla rewrite and a slightly trickier rule involving the [P] flag. Well, conceptually trickier: on paper all you're doing is putting [P] instead of [L]. ([P] implies [L], so you don't need both.)

Did you ever say where this rule will be located? I have to assume a <Directory> section in the server, combined with disabling all overrides for that directory so they can't sneak in and put something else in htaccess.

Now, Option B is to proceed directly to a 503 error, and name your "stop-account" page as the ErrorDocument for the whole domain. I kinda think this involves a ProxyErrorOverride, but don't quote me ;)

[moroandrea]

Thanks Lucy24.

I'm definitely hosting the stop-account.html page on the same domain. Put in this way, I was trying more to discover how to manage things like this than effectively worrying about how to stop the site.

It would have been easier to add a 503 and job done, but I was curious :)

[Dideved]

---

System: The following 3 messages were cut out of thread at: http://www.webmasterworld.com/apache/4580126.htm [webmasterworld.com] by phranque - 1:08 am on Jun 2, 2013 (utc -7)

---

g1, if you are back in the land of the living I wish you would have a look at this recent thread [webmasterworld.com]. While experimenting I discovered something I can't explain, no way, no how-- and the identical thing happens on two different Apache installations.

About the mod_dir behavior? I'm hoping we can manage at least a temporary truce, because I've been trying to deduce its behavior too. Here are some tests I've tried:

# Will mod_dir or mod_rewrite get to process this?
RewriteRule ^$ rewrite-intercepted-root.html

And after a request for "/", the logs showed:

[initial] strip per-dir prefix: C:/Apache24/htdocs/ -> 
[initial] applying pattern '^$' to uri ''
[initial] rewrite '' -> 'rewrite-intercepted-root.html'
[initial] add per-dir prefix: rewrite-intercepted-root.html -> C:/Apache24/htdocs/rewrite-intercepted-root.html
[initial] strip document_root prefix: C:/Apache24/htdocs/rewrite-intercepted-root.html -> /rewrite-intercepted-root.html
[initial] internal redirect with /rewrite-intercepted-root.html [INTERNAL REDIRECT]
[subreq] strip per-dir prefix: C:/Apache24/htdocs/index.html -> index.html
[subreq] applying pattern '^$' to uri 'index.html'
[subreq] pass through C:/Apache24/htdocs/index.html
Response sent with status 200, headers:

Based on this, it looks like mod_dir executes *after* mod_rewrite, though mod_dir seems to ignore the result of the rewrite. It's also worth noticing that the mod_dir subrequest applied our rewrite rules again, which means we could have matched "index.html" and rewritten it to something else during mod_dir's subrequest.

If we were to change this internal rewrite to an external redirect, that would be a game changer.

RewriteRule ^$ /rewrite-intercepted-root.html [R,L]

[initial] strip per-dir prefix: C:/Apache24/htdocs/ -> 
[initial] applying pattern '^$' to uri ''
[initial] rewrite '' -> '/rewrite-intercepted-root.html'
[initial] explicitly forcing redirect with http://localhost/rewrite-intercepted-root.html
[initial] escaping http://localhost/rewrite-intercepted-root.html for redirect
[initial] redirect to http://localhost/rewrite-intercepted-root.html [REDIRECT/302]
Response sent with status 302, headers:

We already know from the first test that mod_rewrite executes before mod_dir. This last test shows that when mod_rewrite results in an external redirect, it sends that response right away, and no other modules -- such as mod_dir -- are given the chance to run.

Now here's where things get really interesting. A while back there was a person who wanted requests for "/index.html" to redirect to "/". One of the patterns we were debating was:

RewriteRule ^(.*/)?index\.html$ /$1 [R,L]

It was thought that this would result in a loop -- the rewrite would redirect "/index.html" to "/", then mod_dir would redirect "/" to "/index.html", then rewrite would... and so on. But it didn't happen that way. Given an htaccess of:

RewriteRule ^(.*/)?index\.html$ /$1 [R,L]

RewriteRule ^$ rewrite-intercepted-root.html

And after a request for "/index.html", the logs showed:

[initial] strip per-dir prefix: C:/Apache24/htdocs/index.html -> index.html
[initial] applying pattern '^(.*/)?index\\.html$' to uri 'index.html'
[initial] rewrite 'index.html' -> '/'
[initial] explicitly forcing redirect with http://localhost/
[initial] escaping http://localhost/ for redirect
[initial] redirect to http://localhost/ [REDIRECT/302]
Response sent with status 302, headers:

----

[initial] strip per-dir prefix: C:/Apache24/htdocs/ -> 
[initial] applying pattern '^(.*/)?index\\.html$' to uri ''
[initial] strip per-dir prefix: C:/Apache24/htdocs/ -> 
[initial] applying pattern '^$' to uri ''
[initial] rewrite '' -> 'rewrite-intercepted-root.html'
[initial] add per-dir prefix: rewrite-intercepted-root.html -> C:/Apache24/htdocs/rewrite-intercepted-root.html
[initial] strip document_root prefix: C:/Apache24/htdocs/rewrite-intercepted-root.html -> /rewrite-intercepted-root.html
[initial] internal redirect with /rewrite-intercepted-root.html [INTERNAL REDIRECT]
[subreq] strip per-dir prefix: C:/Apache24/htdocs/index.html -> index.html
[subreq] applying pattern '^$' to uri 'index.html'
[subreq] pass through C:/Apache24/htdocs/index.html
Response sent with status 200, headers:

The first response is as expected. And the first *half* of the second response behaves the same way we saw in the first test -- rewrites happen first, but mod_dir ignores them. The interesting part happens during the mod_dir subrequest. Of the two rewrite rules, only the second one -- the non-redirect rule -- is applied. Could it be that mod_dir subrequests ignore rewrite rules that have a redirect flag? I added a couple extra rules to be sure:

RewriteRule ^(.*/)?index\.html$ /$1 [R,L]

RewriteRule ^$ rewrite-intercepted-root.html

RewriteRule ^mod_dir-will-apply-this$ /
RewriteRule ^mod_dir-will-not-apply-this$ / [R]

And indeed the log for the mod_dir subrequest showed this:

strip per-dir prefix: C:/Apache24/htdocs/index.html -> index.html
applying pattern '^$' to uri 'index.html'
strip per-dir prefix: C:/Apache24/htdocs/index.html -> index.html
applying pattern '^mod_dir-will-apply-this$' to uri 'index.html'
pass through C:/Apache24/htdocs/index.html

So it would seem that mod_dir's strange behavior can be summed up as:

1. mod_dir will run after mod_rewrite, but it will ignore the result of the rewrite, unless the rewrite results in an external redirect, in which case mod_dir won't run.

2. mod_dir will issue a subrequest, and our rewrite rules can modify that subrequest, but only *some* of our rules will be applied. A redirect flag is one of possibly many factors that will exclude a rewrite rule from being applied to a mod_dir subrequest.

[edited by: phranque at 8:12 am (utc) on Jun 2, 2013]
[edit reason] clean up system tracks [/edit]

[lucy24]

mod_dir will run after mod_rewrite, but it will ignore the result of the rewrite

It can't, or you would never be able to rewrite to a directory index page.

/dunnykin/ has an index.html page
/hoosegow/ does not

RewriteRule hoosegow /dunnykin/ [L]
>> request for /hoosegow/ yields content of /dunnykin/index.html (which can only happen via mod_dir)

But
RewriteRule hoosegow /dunnykin [L]
>> request for /hoosegow/ creates redirect to /dunnykin/ (mod_dir doing its other job)
This is important to bear in mind because it shows how a carelessly worded internal rewrite can result in a wholly unintended external redirect with possibly unintended consequences.

And
RewriteRule \.php - [F]
>> request for /hoosegow/ with auto-indexing enabled results in 403 page because Apache uses php to construct index

but
RewriteRule \.php - [F,NS]
>> now you are good to go.

[Dideved]

request for /hoosegow/ yields content of /dunnykin/index.html (which can only happen via mod_dir)

Indeed. The logs reveal some interesting and perhaps convoluted behavior. Logs are below with a few comments inserted.

# Things start off simple and straightforward.
# A request for "/hoosegow/" is rewritten to "/dunnykin/".

[initial] strip per-dir prefix: C:/Apache24/htdocs/hoosegow/ -> hoosegow/
[initial] applying pattern 'hoosegow' to uri 'hoosegow/'
[initial] rewrite 'hoosegow/' -> '/dunnykin/'
[initial] internal redirect with /dunnykin/ [INTERNAL REDIRECT]

# Next, mod_dir issues a subrequest.
# But it isn't looking for "dunnykin/index.html",
# it's looking for "hoosegow/index.html",
# as if the previous rewrite didn't happen.
# The rewrite rule is re-applied to this subrequest,
# and "hoosegow/index.html" is rewritten to "/dunnykin/".

[subreq] strip per-dir prefix: C:/Apache24/htdocs/hoosegow/index.html -> hoosegow/index.html
[subreq] applying pattern 'hoosegow' to uri 'hoosegow/index.html'
[subreq] rewrite 'hoosegow/index.html' -> '/dunnykin/'
[subreq] internal redirect with /dunnykin/ [INTERNAL REDIRECT]

# An internal redirect finally took place, evidenced by "initial/redir#1".
# The rewrite rules are applied again, but this time the request is for "/dunnykin/",
# so the rewrite patterns don't match.

[initial/redir#1] strip per-dir prefix: C:/Apache24/htdocs/dunnykin/ -> dunnykin/
[initial/redir#1] applying pattern 'hoosegow' to uri 'dunnykin/'
[initial/redir#1] pass through C:/Apache24/htdocs/dunnykin/

# mod_dir issues another subrequest, finally this time for "dunnykin/index.html".

[subreq] strip per-dir prefix: C:/Apache24/htdocs/dunnykin/index.html -> dunnykin/index.html
[subreq] applying pattern 'hoosegow' to uri 'dunnykin/index.html'
[subreq] pass through C:/Apache24/htdocs/dunnykin/index.html

Response sent with status 200, headers:

[g1smd]

Every time you post a RewriteRule without an [L] flag (unless it is one with an [F] or [G] flag where the [L] is implied), a kitten dies.

[Dideved]

Every time you post a RewriteRule without an [L] flag (unless it is one with an [F] or [G] flag where the [L] is implied), a kitten dies.

Thanks for giving us yet another "rule" that is not widely accepted in the web community. And thanks for not providing any rationale. It saves us from having to think. ;)

[lucy24]

Every time you post a RewriteRule without an [L] flag (unless it is one with an [F] or [G] flag where the [L] is implied), a kitten dies.

Where's the "lol" icon when you need it?

moroandrea, the explanation for this one is: Some RewriteRules carry an implied "L", meaning "You're done with mod_rewrite for now, so move on to the next module". That includes [F] [G] [P] and one or two others-- but notably not [R]. This is counter-intuitive, because 99 times out of 100 you would expect a redirect to be the last word. It's only because of that other 1/100 that you have to say [L] explicitly. In real life, probably closer to 1 out of 1000.

[Dideved]

...but notably not [R].

Absolutely. If the suggestion is to always use "L" with redirects, then the official documentation agrees (yay!). I'm hoping this is what g1 meant to say.