Forum Moderators: phranque

Message Too Old, No Replies

PLEASE can you point me to a decent tutorial?

.htaccess - remove one parameter from query string

         

cherryaa

9:06 pm on Jul 30, 2010 (gmt 0)

10+ Year Member



Hello - I'm new & not very good at server modules, so thought it better to ask for tutorial guidance rather than specific help.

I need to strip one parameter out of a url query string. This param is always the same, but I can't get rid of it. I've been googling for a day & a half, without finding the correct advice!

Or maybe I'm applying it wrong ... :O

I'm on Apache 2.2.14.

g1smd

12:37 am on Jul 31, 2010 (gmt 0)

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



URLs are defined in links so you need to change the links on the page to no longer include that parameter.

Once it is removed, you'll no longer receive requests at the server for that parameter.

jdMorgan

12:38 am on Jul 31, 2010 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



The following mod_rewrite rule removes the "lang=<value>" query parameter from all requested URL-paths:

RewriteCond %{THE_REQUEST} ^[A-Z]+\ /[^?]*\?(([^&]*)&)*lang=en(&[\ ]*)?\ HTTP/
# accept optional parm(s) before lang= name/value, but none after
RewriteCond %{QUERY_STRING} ^(([^&]*(&[^&]*)*)&)?lang=en$ [OR]
# require parm(s) before and accept optional parm(s) after lang= name/value
RewriteCond %{QUERY_STRING} ^(([^&]*(&[^&]*)*)&)lang=en((&[^&]*)*)$
RewriteRule ^(.*)$ http://www.example.com/$1?%2%4 [R=301,L]

The code assumes that you wish to re-insert that parameter with a later rule -- but only for internal use inside the server (and not showing in the URL). If this is not the case, then you may omit the first RewriteCond.

It would also be advisable to make the URL-path specification more specific. As it stands, this rule will execute for any requested URL-path, and it might not be a good idea to waste server CPU time looking to strip the "lang=" paramter from, say, URL-paths like "/images/logo.gif"

To be clear on the term, a URL-path contains only the "local" URL, and not the hostname or any query strings appended to the requested URL.

Jim

cherryaa

2:59 am on Jul 31, 2010 (gmt 0)

10+ Year Member



Oh, JOY! Thank you very much, Jim!

@g1smd - The param is being dynamically written by inherited code. I've wasted so long trying to find & eliminate it, this was my last hope! (Not that it turned out to be much of a time-saver: I'd still be here Monday, if not for jdMorgan's advice above.)

Definitely need to find some decent tutorials ...

jdMorgan

4:19 am on Jul 31, 2010 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



A redirect can't really be used to 'fix' incorrectly-generated URLs being published on a site. If the site's scripting continues to publish bad URLs in links, and if you routinely redirect all requests for those URLs, you'll end up wasting visitor's time (they have to wait while their browser fetches the 'bad' URL, and then again when it fetches the redirected-to 'good' URL), and search engines are likely to consider your site as having 'poor technical quality' if it continues to link to URLs that always get redirected.

I can't say how important that might be as a search ranking factor, but it can't help.

Also, note that your stats and log analyses will be skewed by having two requests logged for each of these redirected requests.

The place to fix URLs is wherever they are generated and/or published. Using redirects is mostly useful for correcting errors on third-party sites and for expediting the update of search engine listings when a published URL is changed.

Jim

cherryaa

5:12 am on Jul 31, 2010 (gmt 0)

10+ Year Member



You're right, of course. I can't say I'm worried about search engines & so on, as I'm working on the owner's admin area. The redirect has impaired functionality - but has helped to mask errors caused by the outdated PHP!

At least they can use their admin while I trawl around for the errors at source. Thanks again :)

jdMorgan

11:51 am on Jul 31, 2010 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



As noted above, the redirect is invoked based only on the presence of the query string parameter to be removed. You may be able to reduce or eliminate the "impairment" of the site's functionality by using a more-specific RewriteRule pattern to restrict the invocation of the redirect to URLs where that query string's presence actually causes a problem.

Alternately, a RewriteCond with a negative-match pattern could be used to exclude particular directory-paths or URLs where you do not wish the rule to be invoked.

For example, if only requests for .php URL-paths should be redirected, and this should be done in all except the "admin/" area, then ending the RewriteRule pattern with "\.php$" and using a RewriteCond to exclude the "admin/" path would do that.

Jim

cherryaa

5:03 pm on Jul 31, 2010 (gmt 0)

10+ Year Member



Excellent! Yep, I put the .htaccess in the admin directory and set the url path to "\.php$"

And now I think I've fixed the glitch :D
You saved my weekend.

g1smd

10:33 pm on Jul 31, 2010 (gmt 0)

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



Beware that the root
.htaccess
file is processed first, so you might need to look carefully at the rules in there, with a view to adding an exclusion to some of the rules for
/admin
requests.