[OT] URL redirection (was: Reorg of D site)
Stewart Gordon
smjg_1998 at yahoo.com
Fri Apr 18 10:24:46 PDT 2008
"Unknown W. Brackets" <unknown at simplemachines.org> wrote in message
news:fu97a9$1lgv$1 at digitalmars.com...
> You're pretty much right in everything you've said... but some clarifying
> points:
>
> 1. See the spec <http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html>.
>
> Here the important status codes are "302", "303" and "307". Essentially,
> 307 is 302... created because almost every client and server treats 302 as
> if it were 303. You pretty much have to.
So effectively, the 307 code was created to supersede 302 because many UAs
were mishandling 302 as 303. A bit like the way the .biz TLD was created to
attempt to sort the men from the boys (misusers of .com for vanity sites and
the like).
> 2. 301 is sometimes overused, because it will carry Google page rank while
> other 3xx codes will not.
What do you mean by "carry Google page rank"?
> 301 is also normally cached, unlike the others which normally aren't (even
> if cache headers say to, most clients and proxies ignore them.)
So that explains something. In the days when I used a URL redirection
provider for my personal website, I would sometimes find Google expanding my
redirecting URL to its own cache of the redirect's destination. It just
shows one of the problems with redirectors using the wrong status code.
> 3. Refresh using <meta /> is essentially the worst case. It provides a
> worse experience for the user (Refresh cannot happen until the source page
> finishes loading)
How do you work that out?
, it relies on HTML (so obviously cannot work for
> images, RSS feeds and other content delivered over HTTP), there are
> syntaxes of <meta http-equiv="Refresh" /> which are not supported by all
> clients, etc., etc.
What are these syntaxes? Are they ever necessary for such simple
redirection?
> 4. Note that the <meta http-requiv="" /> element/attribute pair exists to
> emulate an HTTP header in HTML. Technically, one could send a Refresh
> header over HTTP (which would be ignored by many clients mind you) but no
> one would ever do that...
>
> 5. Your example is probably overdoing it. If someone has a client that
> doesn't support/allow you to Refresh, it's unlikely JavaScript will do you
> any better. It's probably a waste of bandwidth. And, clearly, 301 is
> better in every case for this specific example...
<snip top of upside-down reply>
That's half the reason I said "provide a means of disabling it". I'm not
sure I've ever seen a client that doesn't support meta refresh at all.
Before I took over that website and undertook to clean it up, the root URL
was redirected using only JS, and anybody who has JS disabled would just see
a blank page.
But that said, if the user has disabled meta refresh, should I really use JS
to bypass it? CTTAI if they hate meta refresh enough to want to disable it,
I guess they'd equally hate JS doing the same....
Stewart.
More information about the Digitalmars-d-announce
mailing list