homepage Welcome to WebmasterWorld Guest from 54.196.159.11
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / Code, Content, and Presentation / Apache Web Server
Forum Library, Charter, Moderators: Ocean10000 & incrediBILL & phranque

Apache Web Server Forum

    
Is this possible with .htaccess?
mattzer




msg:4471004
 5:15 pm on Jun 29, 2012 (gmt 0)

Hi,

I want to redirect the the following series of pages-

/Product/page/2/
/Product/page/3/

and so forth (theres like 25 pages total), to-

/product/page/2/
/product/page/3/

The only difference is the lowercase P.

Is it possible to do all of that in .htaccess?

To be honest I have no idea what I'm doing, over the past hour from reading around I have come up with-

RewriteRule ^Product/page/?$ /product/page/$1/1 [R=301,L]

But that doesnt work at all :)

Where is my mistake?

Thank you for your time

 

mattzer




msg:4471005
 5:20 pm on Jun 29, 2012 (gmt 0)

BOOM

RewriteRule ^Product/page/(.*)$ /product/page/$1 [R=301,L]
g1smd




msg:4471013
 5:36 pm on Jun 29, 2012 (gmt 0)

Nearly.

Add the protocol and domain name to the rule target.

Make sure this rule is before your non-www/www redirect.

If the (.*) bit is always a number, use ([0-9]+) instead. No need to redirect duff requests.

You might need a separate rule before this to handle page 1 properly.

seoskunk




msg:4471116
 11:23 pm on Jun 29, 2012 (gmt 0)

I had a similar issue recently and I will say this first, Internet protocol determines that website addresses and urls should not be case sensitive. The best solution here is to show both the upper case (or mixed case) and lower case version of the page. No redirect should be required at all.

g1smd




msg:4471120
 11:49 pm on Jun 29, 2012 (gmt 0)

The hostname should not be case sensitive.

Paths and filenames are case sensitive.

Apache gets this right. IIS server software and badly coded CMS software gets it wrong.

incrediBILL




msg:4471157
 4:03 am on Jun 30, 2012 (gmt 0)

The best solution here is to show both the upper case (or mixed case) and lower case version of the page. No redirect should be required at all.

That causes canonicalization problems in the search engines as those are two distinctly different paths showing the same content.

The redirect to the preferred path solves that problem.

seoskunk




msg:4471551
 6:39 pm on Jul 1, 2012 (gmt 0)

That causes canonicalization problems in the search engines as those are two distinctly different paths showing the same content.


I have to say first I have NEVER seen a canonical issue with the SAME PATH using capitalization in urls.

A static url would show the same content with capitalization and as rewrites choose to emulate static urls so should they.

glsmd says
Apache gets this right. IIS server software and badly coded CMS software gets it wrong.


I totally agree

g1smd




msg:4471552
 6:42 pm on Jul 1, 2012 (gmt 0)

I have to say first I have NEVER seen a canonical issue with the SAME PATH using capitalization in urls.

I have. I'm in the middle of dealing with a site that has 80 000 duplicate content URLs, a sizeable proportion of them caused by casing issues.

seoskunk




msg:4471554
 6:50 pm on Jul 1, 2012 (gmt 0)

g1smd if thats the case then the SE is at fault. The Uniform resource locator should not be case sensitive as outlined by Tim Berners Lee. Static urls are not case sensitive so why on earth should rewrites?

g1smd




msg:4471563
 8:28 pm on Jul 1, 2012 (gmt 0)

[w3.org...] states that hostnames are not case sensitive, but the rest of the URL is.

The Uniform resource locator should not be case sensitive as outlined by Tim Berners Lee.

Perhaps you can point out where that is stated.

legaleagle




msg:4471568
 8:56 pm on Jul 1, 2012 (gmt 0)

I always use lc urls

seoskunk




msg:4471576
 9:23 pm on Jul 1, 2012 (gmt 0)

A full BNF description of the URL syntax is given in Section 5.

In general, URLs are written as follows:

<scheme>:<scheme-specific-part>

A URL contains the name of the scheme being used (<scheme>) followed
by a colon and then a string (the <scheme-specific-part>) whose
interpretation depends on the scheme.

Scheme names consist of a sequence of characters. The lower case
letters "a"--"z", digits, and the characters plus ("+"), period
("."), and hyphen ("-") are allowed.For resiliency, programs
interpreting URLs should treat upper case letters as equivalent to
lower case
in scheme names (e.g., allow "HTTP" as well as "http").



[ietf.org...]

This to me says anything following the colon should not be case sensitive.

g1smd




msg:4471577
 9:28 pm on Jul 1, 2012 (gmt 0)

NO. It's talking about "scheme names", allowing http:// HTTP:// and HttP:// as equivalent.

In http the hostname is also case insensitive.

In http the path and file are case sensitive.

seoskunk




msg:4471579
 9:35 pm on Jul 1, 2012 (gmt 0)

The great thing about forums is ability to share and learn. I had always interpreted this as all urls but g1smd has made me rethink this. Its an example of a shared opinion opening up a previously fixed opinion.

Thanks g1smd for making me see this from a new perspective.

wilderness




msg:4471580
 9:38 pm on Jul 1, 2012 (gmt 0)

mixed-case paths are an excellent method of detecting lame bots.

lucy24




msg:4471586
 10:00 pm on Jul 1, 2012 (gmt 0)

I always use lc urls

Good habit. But the most important thing is to treat everything as if it's case-sensitive, even if your current server (or your home computer) doesn't care.

All subsequent posts came in after I opened the tab, so there may be overlap.

How 'bout this [w3.org]? (Boldface in the original; note final sentence. Within this selection, text is continuous.)

When is a URI "the same URI"?

Two URIs are the same if (and only if) they are the same character for character.

Two URIs which are different may in fact be equivalent, in that they may refer to the same thing, and give the same result in all operations. In some cases any agent looking at two URIs can deduce, from knowledge of the various web standards, that they must be equivalent, in that they must refer to the same thing. For example, HTTP URIs contain domain names, and the Domain Name System is case-insensitive. Therefore, while it is normal practice to use lower case for domain names, any agent which comes across two URIs which differ only in the case of the domain name can conclude that they must refer to the same thing. In another case, a client agent may use out-of-band information about a web site to know that its URI paths are case-invariant, or that URIs ending in "/" and "/index.html" are equivalent. It is bad engineering practice to make new protocols require such processing.

There are a long series of such algorithms. Which ones an agent can apply depends on what information it has to hand, and depend on what knowledge of which protocols has been programmed into it. New schemes may be defined in the future, for which different forms of canonicalization can be done. There is, therefore, no definitive canonicalization algorithm for URIs. Generic URI handling code should handle URIs as case-sensitive character strings.

incrediBILL




msg:4471617
 4:09 am on Jul 2, 2012 (gmt 0)

Its an example of a shared opinion opening up a previously fixed opinion.


The canonicalization issue isn't an opinion, it's a fact.

Implemented correctly, this will not be a problem.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / Apache Web Server
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved