Forum Moderators: phranque

Message Too Old, No Replies

Problem with Rewritecond %{query string}

         

stormshield

2:49 pm on Aug 13, 2008 (gmt 0)

10+ Year Member



Hi,

Rewritecond %{query_string} ^letter=(.*)$
RewriteRule ^folder/([^/]*)/alphabet$ /folder2/$1/%1 [R=301,L]

I'd like this:

[mysite.com...] -->
[mysite.com...]

What I get instead is: [mysite.com...]

So basically I can't get rid of the query string.

Thanks,
Storm

stormshield

2:52 pm on Aug 13, 2008 (gmt 0)

10+ Year Member



OK. Stumbled across this [httpd.apache.org...] and it dissolved my doubts. You need to put a question mark after %1.

;)

jdMorgan

5:15 pm on Aug 13, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



I'd also advise two more things:

One, go by the book on everything -- Do NOT feel free to change anything from the examples you see at apache.org -- Type the directives and variable names exactly as shown to avoid compatibility/portability problems; mod_rewrite is not a "forgiving" or flexible general-purpose programming language.

Two, make your patterns as specific as possible. This may improve performance, prevent unexpected results, and make it easier to maintain your code. For example, your rule may fail if you ever add another query string parameter ahead of or behind "letter", or if someone links to you with a double slash after "folder".

Try:


RewriteCond %{QUERY_STRING} &?letter=([^&]+)&?
RewriteRule ^folder/([^/]+)/alphabet$ /folder2/$1/%1? [R=301,L]

Jim

stormshield

5:38 pm on Aug 13, 2008 (gmt 0)

10+ Year Member



Jim, That's true. Thank you.

g1smd

7:36 pm on Aug 13, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Personally, I would also fix up the domain at the same time:

RewriteCond %{QUERY_STRING} &?letter=([^&]+)&?
RewriteRule ^folder/([^/]+)/alphabet$ http://www.domain.com/folder2/$1/%1? [R=301,L]

jdMorgan

9:04 pm on Aug 13, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Since this appears to be an internal-rewrite application, domain canonicalization should be done in a separate rule -- a redirect-- unless it is desired that "/folder" be exposed to users and to search engines.

Jim

g1smd

9:42 pm on Aug 13, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



The [R=301] on the end suggested this already was coded as a redirect.

I'm confused now as to whether the OP needed a redirect from an old URL to a new URL, or whether the OP needed a rewrite from the new URL to the old internal server filepath - or both.

stormshield

10:13 pm on Aug 13, 2008 (gmt 0)

10+ Year Member



Yes, it's a redirect.

I'm redirecting old URL to a new one.

or whether the OP needed a rewrite from the new URL to the old internal server filepath

To be honest, I have no idea how internal server rewrites work. Could you give me an example?

jdMorgan

10:41 pm on Aug 13, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



The thread "What's the difference between a redirect and a rewrite? [webmasterworld.com]" in our Apache forum Library, may help answer your question.

Jim

stormshield

4:19 pm on Aug 14, 2008 (gmt 0)

10+ Year Member



So, when making redirects, using full urls is a must? why? Relative urls seem just fine.

jdMorgan

4:56 pm on Aug 14, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Go by the book -- or suffer the consequences. Using only a local-URL-path can cause problems with domain canonicalization, because -as documented- the server will default to using ServerName in the absence of a full URL. If your preferred domain is "www.example.com" and you have a redirect in place to enforce this, but ServerName is set to "example.com" (no "www") and UseCanonicalName is set to "on", then the result will be two redirects in a row -- the first one as coded without the full URL, and the second to "correct" non-www to www. The major search engines will pass PageRank/Link-popularity through one 301 redirect, but not through two.

"This is absolutely correct according to the documentation and I've tested it thoroughly" is a much more robust approach to configuring your server than "It seems to work fine." It is possible to make a very good living correcting the unintended functional and search ranking consequences of "only-slightly-incorrect" coding in server config files...

Jim

g1smd

7:35 pm on Aug 14, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



If I ask for /file.html and you externally 301 redirect that request to /other.html, then that redirect will work for both domain.com and for www.domain.com and will not fix up the domain. That's a Duplicate Content issue.

You might have some other rule that fixes up non-www requests by redirecting them to www.domain.com but that will lead to a redirection chain, two back-to-back redirects.

So, you fix that by making sure that while redirecting the specific filename, you also fix the domain at the same time in the same redirect.

Your generic non-www to www 301 redirect will be placed after the specific-filename rule in your .htaccess file and it will catch all of the other non-www requests.

Your Duplicate Content issue, and the redirection chain have now both been designed out.

stormshield

8:19 pm on Aug 14, 2008 (gmt 0)

10+ Year Member



Heck, I never fully realized that! Lots of PR may have been lost on my sites due to this, I guess. I used to do something like this:
page A redirects to page B
page B redirects to page C

I'm wondering: if I get rid of my old "double" 301 redirects (by redirecting A directly to C), will PR be restored?

Thanks

g1smd

8:28 pm on Aug 14, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



It might be. Let's at least say that it can't harm you to fix it.

g1smd

8:37 pm on Aug 14, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Now that you have a handle on redirects (they typically include both the target domain name, and R=301) let's look at rewrites.

A rewrite connects a URL request to an internal filepath that is different to the one that would normally be expected from the URL request.

A request for domain.com/file.html is rewritten to pull some other file, such as other.html, from the server, without exposing the name or path of that file.

A rewrite will NOT include the domain name and will not include a R=nnn parameter either.

Note: Including the domain name always makes it a 302 redirect unless you also add R=301 to make it a 301 redirect.

A rewrite internally rewrites a URL request to an alternative internal filepath, something like:

RewriteRule ^file.html /elsewhere/other.html [L]

Rewrites must always be placed after all of your redirects, otherwise you risk exposing the internal filepath as a new URL.

[edited by: g1smd at 8:43 pm (utc) on Aug. 14, 2008]

stormshield

8:41 pm on Aug 14, 2008 (gmt 0)

10+ Year Member



By the way, what's the best way to find your double redirects?

g1smd

8:44 pm on Aug 14, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Use the Live HTTP Headers extension for Mozilla Firefox or Mozilla Seamonkey.

stormshield

8:48 pm on Aug 14, 2008 (gmt 0)

10+ Year Member



Rewrites must always be placed after all of your redirects, otherwise you risk exposing the internal filepath as a new URL

What about non-www->www?
RewriteCond %{HTTP_HOST} ^example\.com [NC]
RewriteRule (.*) http://www.example.com/$1 [R=301,L]

Should it be at the very bottom of all redirect requests?

jdMorgan

9:01 pm on Aug 14, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



After all other more-specific external redirects, and before any internal rewrites.

Jim

stormshield

9:06 pm on Aug 14, 2008 (gmt 0)

10+ Year Member



Thanks. I always placed wherever I could :)

g1smd

9:13 pm on Aug 14, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Redirects always interact with the browser. They force the browser to make a new request to the server for a new URL. The user sees the new URL.

Rewrites silently pull the content from the server, but from a different place in the filesystem to what may have been expected. The filepath should not be exposed.

If you put redirects after rewrites you risk exposing the supposedly secret internal filepath to the outside world.