What's the difference between an external redirect and an internal rewrite?

Redirecting versus rewriting

[Marcia]

I keep seeing references to internal vs internal redirects in posts, but have searched and searched all over, and found no information on what the difference is.

What's the difference between them? And how is one done as opposed to how the other is done?

[wilderness]

Marcia,
an internal is a relative path.

An external is a complete path, and/or a complete path to another website as well.

[Marcia]

I've only seen it with reference to redirects within the same domain. That's what I find confusing.

[jdMorgan]

Hopefully, you're asking about external redirects versus internal rewrites -- Note that both words in these two-word phrases differ.

With an external redirect, your server issues a response telling the requesting client, "That resource has moved - Ask for that content again using this new URL." At this point, the current HTTP request is terminated. The client (e.g. browser or robot) then starts a new HTTP transaction, re-requesting the desired resource using the new URL provided by the server. Because it is a new HTTP request, a browser will update its address bar to show the new URL.

External Redirect:
Client: Issue HTTP request: "GET /page.html"
Server: Send HTTP response: "/page.html has moved, ask for /page2.html instead." Close HTTP request.
Client: Issue HTTP request: "/GET /page2.html" (Note that it is the client's option to follow the redirect.)
Server: Send content of /page2.html, close HTTP request.

In contrast, an internal rewrite simply changes the server filepath associated with a requested URL. If no internal rewriting is applied, then by default, the server uses the part of the requested URL following the domain name as the filepath. But Apache mod_rewrite or ISAPI Rewrite on IIS can be used to completely change the filepath associated with a URL; The most visible example of this is the 'pointing' of all client URL requests to a single page-generation script on a server. Internal rewrites take place within the context of the client's original HTTP request, and the client is unaware that the server filepath used to retrieve or generate the requested content differs from the path-part of the URL it requested.

Internal Rewrite:
Client: Issue HTTP request: "GET /page.html"
Server: Internally rewrite client-requested URL "/page.html" to server filepath "/page2.html", send content of "/page2.html". Close HTTP request.

So, short version:
External Redirect = Tell client to ask for the requested content again using a new URL and HTTP request.
Internal Rewrite == Get content for requested URL from a different server filepath than implied by the requested URL.

The confusion over external redirects and internal rewrites is widespread; Even the Apache documentation frequently refers to "internal redirects" when internal rewrites are being discussed. And mod_rewrite, despite its name, can do internal rewrites, external redirects, or proxy through-puts, depending on the syntax of the mod_rewrite RewriteRule directive used.

Jim

[gergoe]

Excellent explanation, how about putting it in the library?

[phranque]

this is the relevant apache RewriteRule documentation [httpd.apache.org], especially the section on the "redirect" substitution flag and the notation on absolute url substitution.

[itsraghz]

That was a very great explanation.

thank you jdMorgan.

[Marcia]

Thank you! But just to clarify with a practical example, the code in this thread for canonical issues and multiple domains would be internal rewrites, is that right?

[webmasterworld.com...]

But redirecting using Redirect or RedirectMatch using mod_alias would be external redirects?

[phranque]

marcia, if you read the referenced section of the apache RewriteRule documentation linked above, you would see that the "R=301" immediately tells you that a permanent external redirect is being forced.

also if you think about it conceptually, you could not solve any canonical domain issues without informing the user agent, which can't be accomplished with an internal rewrite.

typically (hopefully?) an internal rewrite returns a "200 OK" which means "i got it!"
an external redirect necessarily returns a 301 or 302 which means "i've moved!"

[Marcia]

marcia, if you read the referenced section of the apache RewriteRule documentation linked above, you would see that the "R=301" immediately tells you that a permanent external redirect is being forced.

Ummm... excuse me please, but I most certainly have read it. Maybe I missed it, so maybe you could be specific with the place or copy and paste the part where it's specific (and clear) about permanent external.

I know it's a 301 and I know what the flags are and what they're for; I use it all the time, on every single site, without exception. But what's confusing to people is differentiating between the concepts of internal and external, which is about as clear as mud in the documentation.

jdMorgan:

The confusion over external redirects and internal rewrites is widespread; Even the Apache documentation frequently refers to "internal redirects" when internal rewrites are being discussed. And mod_rewrite, despite its name, can do internal rewrites, external redirects, or proxy through-puts, depending on the syntax of the mod_rewrite RewriteRule directive used.

I've read the Apache documentation! But the documentation isn't clear, which is why people ask questions in forums, and is why a lot of people spend a lot of money buying books - including me. ;)

[edited by: Marcia at 11:16 am (utc) on Jan. 16, 2008]

[phranque]

most simply stated, internal means the server uses a resource at a different url without telling the browser and external means telling the browser to request a resource at a different url.

at i can tell you "as clear as an azure sky of deepest summer" that when you see a 301 or 302 it is an external redirect.
if you see the "R" flag in the RewriteRule it is an external redirect.
if it is a fully qualified (including domain) url it is an external redirect.
if the browser knows about it (such as a change in the address field) it is an external redirect.

if there is no R flag in the RewriteRule and it is a relative url it is an internal rewrite.

having said that, one "click" on a link can generate a chain of external redirects, temporary and/or permanent, and each of those external redirects could have been generated after a series of internal rewrites.
so i'm quite in agreement on the clarity of mud - it makes my head hurt sometimes...

[phranque]

here is the referenced section of the doc at [httpd.apache.org...]

'redirect¦R [=code]' (force redirect)
Prefix Substitution with http://thishost[:thisport]/ (which makes the new URL a URI) to force a external redirection. If no code is given, a HTTP response of 302 (MOVED TEMPORARILY) will be returned. If you want to use other response codes in the range 300-400, simply specify the appropriate number or use one of the following symbolic names: temp (default), permanent, seeother. Use this for rules to canonicalize the URL and return it to the client - to translate ``/~'' into ``/u/'', or to always append a slash to /u/user, etc.
Note: When you use this flag, make sure that the substitution field is a valid URL! Otherwise, you will be redirecting to an invalid location. Remember that this flag on its own will only prepend http://thishost[:thisport]/ to the URL, and rewriting will continue. Usually, you will want to stop rewriting at this point, and redirect immediately. To stop rewriting, you should add the 'L' flag.

[edited by: jdMorgan at 3:41 am (utc) on Jan. 17, 2008]
[edit reason] De-linked "thishost" [/edit]

[topr8]

>>concepts of internal and external

internal = this is invisible to the client/user, the client requests a page/file but is served a different one but the address in the browser remains the same.

external = visible to the client/user, the client requests a page and the server sends them to another page, the address bar in the browser shows the page that the client has been redirected to not the one they requested.

[Marcia]

>i'm quite in agreement on the clarity of mud - it makes my head hurt sometimes...

Yep, that documentation quoted is about as clear as London fog. But now it's cleared up quite a bit, explained in plain English instead of obfuscated, arcane geekspeak like the docs.

[Marcia]

Now that we've gotten past the off-topic side issue of whether or not people have read the documentation (which they have), that documentation is not at all clear on what the actual format and syntax is of the two. And that is exactly why the issue continues to be clouded: No actual examples, which again - is why people have to buy books. Sheesh, they even recommend an O'Reilly book in the documentation.

Simple examples would make that documentation some clarity and make it a _whole_ lot more useful.