Welcome to WebmasterWorld Guest from

Forum Moderators: Ocean10000 & incrediBILL & phranque

Message Too Old, No Replies

An htaccess redirect not working in G Chrome

not redirecting to '/'

3:54 am on Jan 29, 2011 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Apr 3, 2002
votes: 0

I have noticed traffic coming to my site using www.example.com (no trailing slash), but my haccess specifies a redirect to www.example.com/

The rules work in every browser except Chrome. Give it a try and see if it happens for your domains. I see it happening on webmasterworld, always redirects to no trailing slash. Maybe this is just how Chrome displays it? Does anyone else see this? It's really more of an annoyance because it is distorting my entry-page statistics.
5:45 pm on Jan 29, 2011 (gmt 0)

Junior Member

10+ Year Member

joined:July 15, 2006
posts: 78
votes: 0

In G Chrome we see the same effect as described
3:07 am on Feb 1, 2011 (gmt 0)

Senior Member

WebmasterWorld Senior Member jdmorgan is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:Mar 31, 2002
votes: 0

According to my testing over the past few minutes, neither Chrome (AppleWebKit) nor Firefox can be made to send a blank URL-path. This missing slash is not part of the hostname (loosely, the "domain name"), it is part of the URL-path. It is not technically correct to send a blank URL path, and in order to do so, one must send an HTTP request line like
instead of the valid
GET / HTTP/1.1

What I see is that if I type "example.com" into the address bars of Chrome and Firefox, both append the slash when making the request to my servers. However, Firefox shows the corrected URL in its address bar, but Chrome does not. As this is strictly a display issue, it has nothing to do with your htaccess working for one browser versus another.

More likely, the requestors you see in your logs making requests for blank URLs are 'bots masquerading as browsers... I doubt that any modern browser can be made to send a truly-blank request-URI path. Most likely, these are requests from badly-coded scripts. If in doubt, fully-validate all of the HTTP request headers, to include Connection, Accept, Accept-Language, Accept-Encoding, Accept-Charset, etc., and you may find that these are not really the browsers they claim to be...

Note: I do have a rule that detects a blank URL-path in the request line, and I only see it getting invoked by "questionable" user-agents.