[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