On 27 May 2008, at 19:18, Robert Cummings wrote:
On Tue, 2008-05-27 at 18:04 +0100, Stut wrote:
On 27 May 2008, at 17:54, Robert Cummings wrote:
On Tue, 2008-05-27 at 17:10 +0100, Stut wrote:
On 27 May 2008, at 17:06, Yui Hiroaki wrote:
I would like to have some question.
For example,
I am in http://example.com/?12324242
I would like to REDIRECT from http://example.com/?1312323232
to http://example.com/
I can REDIRECT from http://example.com/index.php to http://example.com
Please do tell me how I can redirect!
This is the sample what I test below!
<?php
if ($_SERVER['REQUEST_URI'] == '/index.php') {
header("HTTP/1.1 301 Moved Permanently");
header("Location: http:///example.com/";);
exit();
}
?>
1) Why? Redirects should be avoided where possible for performance
reasons.
Didn't this topic get covered several months back. I always do
redirects
so as not to bugger browser history, titles, indexing, etc. If
someone
requests a page and they need to be logged in, I redirect to the
login
page, I never just present the login page... that's just incorrect
from
Personally I tend to only use redirects when a form handler has done
it's job to avoid evil messages when the user hits back. However, I
have used both redirected and non-redirected login workflows in the
past for various reasons, and I don't believe there is a "standard"
way to do it. It depends on how the site will be used and by whom.
a hierarchical and semantic point of view. Similarly, if I'm doing
404
handling with fuzzy request sniffing to determine what was actually
requested, I again perform a redirect once I've ascertained what was
probably desired. If you don't, then Google and other search engines
will index these malformed URLs instead of the correct URL.
The correct response to a 404 page is 404. No arguments. If you
redirect missing pages then your site effectively contains an
infinite
number of pages. By all means display a useful page when you return
your 404 but not marking it as a missing page does little if anything
for your SEO rank and absolutely nothing for your users.
404 "Not Found", but it was found, but it's not where you asked for
it,
it's over there... we've permanently moved it from here to there (even
if only virtually)... let's redirect you to the correct location.
Since
you perform a redirect to the correct location, the content is
appropriately indexed where it actually exists. If you return a 404
status I'm pretty sure Google discards the content.
If you can successfully fulfil the request then it's not a 404, but I
would question why you're getting requests for URLs that don't exist
but that you can accurately service. If you're using the URL as a
search field then your site truly has no missing pages.
However, in that case it's unlikely you'll be redirecting since for a
lot of queries you'll end up with multiple results meaning you're not
accurately fulfilling the request unless there's only one result from
the search. In that case I would agree that a redirect is the done
thing - except where the user got there by doing a search, which is
where things get cloudy as some would say it's appropriate to show
search results since that's the reasonable user expectation, and
others would say it should redirect to the single result - where I'd
come down on that would depend on the content and average user profile.
*breath!*
If you return a 404 Google does indeed discard the content - that's
the logical thing for it to do. 301's allow it to reduce the URLs
used to access your site to a core set of "real" content. Given that,
I agree to your premise that if you can successfully fulfil the
request by redirecting then you should, but only if it's an accurate
response to the request and not a "best guess". Best guesses should be
presented to the user (and Google) as a page suggesting content and
providing other ways to find it if your suggestion is not correct.
I'm starting to ramble so I'll stop here. I hope the point I'm making
is clear in there somewhere.
IMHO if you're going to use a semantic argument to defend one point
you need to carry that attitude throughout.
My semantic argument is still intact. If I found it, then it's not
deserving of "404 Not Found" status. Sure it may not be at the
requested
location, but that's what the moved status is for.
The 301 status code was created so web developers can re-organise
their websites without adversely affecting the user experience. A side
effect of this is that search engines also use them to keep their
index up to date without affecting the sites ranking.
Here's a physical world analogy. Walk into a hardware store ask for
object X. If they have it they will tell you. If they don't then
either
they will say, "Sorry, we don't have that. I don't have a clue where
you
can get it", or if they do know (and want to help) they'll say "It's
over there at Rob's Hardware Store". What they almost certainly won't
say is hang on, then run over to Rob's hardware Store, buy item X,
come
back and try to sell it to you. Almost certainly, but who knows,
people
do weird things sometimes :)
Taking that analogy a step further, the original hardware store is
unlikely to pick you up and physically take you to Rob's Hardware
Store. In fact you said it... [they'll say "It's over there]... which
in web terms would be a page saying "we couldn't find what you were
looking for where you were looking, but we found it over there".
That's what I'm advocating.
So here's something else since you played the performance card.
Click on
the following link and tell me where you end up when not already
logged
in:
http://mail.google.com/mail/
I'm sure Google had a good reason for that behaviour, as in it's
follows
more correctly the standard expected request behaviour, and I'm sure
they get a LOT of hits ;)
First off I really do wish people would get it out of their heads that
just because a company such as Google does something it's the best or
right way to do it. Secondly there are two separate scenario's that
are being mixed up.
Scenario 1 is redirecting when someone comes into your site from an
incorrect URL. Whether that incorrect URL is incorrect by design or
not is beside the point. For the purposes of bookmarking and search
engine friendliness the logical thing to do here is to redirect to the
correct URL with a 301 status code. As for the Gmail example you cite,
Google uses a single sign-on for all of its services, which is a
different kettle of fish. IOW it was a bad example. They redirect
because the sign-on functionality does not exist within the Gmail app,
it's external (ok, same root domain but you know what I mean).
Scenario 2 is redirecting within the same website. In the case of the
OP he's getting a request for the index page with some info in the
query string. He then wants to redirect to the same page but without
the query string. Let's assume the ID is an affiliate ID and he wants
to get rid of it to have a clean URL for people to bookmark. I can
kinda understand that, and it would come under Scenario 1.
However, the scenario in question is login which land squarely in
scenario 2. I mainly work on a site where 90% of it is accessible
anonymously. When you hit something that requires you to login it
redirects you to the login page. It does this because session handling
is done on a separate cluster. If that was not the case then I'd be
showing the login form inline because it saves the server an HTTP
request, PHP processing and potentially DB access... IOW server-side
resources. That may not be a big deal on small sites but on large busy
sites it could be fatal.
Let's take a step back and look at the HTTP spec. In the good old days
all authenticated access was done through HTTP authentication. If a
resource requiring a login was accessed anonymously the server returns
a status code indicating that a username and password was required.
Note no redirects, just a login form being displayed (albeit by the
browser rather than via HTML).
Ok, having typed that I'm not sure it's relevant, but I can't be arsed
to delete it. My main point is that internal redirects are a waste of
resources if they can be avoided and don't, as far as I can tell,
provide any tangible benefit to anyone.
Feel free to correct me if you think I'm wrong.
-Stut
--
http://stut.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
