On Tue, 22 Jan 2008 20:33:22 -0800
Walter Bright <newshound1@digitalmars.com> wrote:

> As some of you may have noticed, the D 2.0 stuff has all moved into digitalmars.com/d/2.0, instead of digitalmars.com/d. The original files have been replaced with redirects (phew, that was a lot of tedious work).

First an foremost: why didn't you put 1.0 showing up as default on digitalmars.com/d ? I still don't see a point in presenting an instable and experimental branch on the front page.

With Konqueror, on the specification part of the site, there seems to be something wrong with the encoding. Additionally, there's a minor margin/width difference of the menu between the start page and the specification.

> The benefit of this is that the searches are now targeted instead of picking up the whole digitalmars site. (It took about 24 hours for google to reindex the site.)

May I suggest using some sort of content management system? Working 24 hours on a rather small task like that sounds kind of wrong.

-- 
Alexander Panek <alexander.panek@brainsware.org>

Alexander Panek wrote:
> On Tue, 22 Jan 2008 20:33:22 -0800
> Walter Bright <newshound1@digitalmars.com> wrote:
> 
>> As some of you may have noticed, the D 2.0 stuff has all moved into digitalmars.com/d/2.0, instead of digitalmars.com/d. The original
>> files have been replaced with redirects (phew, that was a lot of
>> tedious work).
> 
> First an foremost: why didn't you put 1.0 showing up as default on
> digitalmars.com/d ? I still don't see a point in presenting an instable
> and experimental branch on the front page.
> 
> With Konqueror, on the specification part of the site, there seems to
> be something wrong with the encoding. Additionally, there's a minor
> margin/width difference of the menu between the start page and the
> specification.
> 
>> The benefit of this is that the searches are now targeted instead of picking up the whole digitalmars site. (It took about 24 hours for google to reindex the site.)
> 
> May I suggest using some sort of content management system? Working 24
> hours on a rather small task like that sounds kind of wrong.

Google worked on it for 24 hrs, not Walter.

--bb

Alexander Panek wrote:
> First an foremost: why didn't you put 1.0 showing up as default on
> digitalmars.com/d ? I still don't see a point in presenting an instable
> and experimental branch on the front page.

agreed;


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode

Alexander Panek wrote:
> On Tue, 22 Jan 2008 20:33:22 -0800
> Walter Bright <newshound1@digitalmars.com> wrote:
> 
>> As some of you may have noticed, the D 2.0 stuff has all moved into digitalmars.com/d/2.0, instead of digitalmars.com/d. The original
>> files have been replaced with redirects (phew, that was a lot of
>> tedious work).
> 
> First an foremost: why didn't you put 1.0 showing up as default on
> digitalmars.com/d ? I still don't see a point in presenting an instable
> and experimental branch on the front page.

Or at least put 1.0 and 2.0 links side by side, with a note saying that 1.0 is stable and 2.0 is under active development.

On Fri, 25 Jan 2008 21:35:18 +0900
Bill Baxter <dnewsgroup@billbaxter.com> wrote:

> Alexander Panek wrote:
> > On Tue, 22 Jan 2008 20:33:22 -0800
> > Walter Bright <newshound1@digitalmars.com> wrote:
> >> The benefit of this is that the searches are now targeted instead of picking up the whole digitalmars site. (It took about 24 hours for google to reindex the site.)
> > 
> > May I suggest using some sort of content management system? Working 24 hours on a rather small task like that sounds kind of wrong.
> 
> Google worked on it for 24 hrs, not Walter.

Yes. I've figured that right after posting it. :\

-- 
Alexander Panek <alexander.panek@brainsware.org>

Tom S wrote:
> Alexander Panek wrote:
>> First an foremost: why didn't you put 1.0 showing up as default on
>> digitalmars.com/d ? I still don't see a point in presenting an instable
>> and experimental branch on the front page.
> 
> agreed;
> 
> 

agreed ;) there is too much confusion among newcomers.

"Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:fn891s$1ncq$1@digitalmars.com...
> Yes, a 301 should work like that (as would 302.)

<snip top of upside-down reply>

Yes, HTTP redirection using a status code in the 300s is the best way.  But you should use the right code!

In this instance, the correct code would indeed be 301 (moved permanently). 302 (found) would probably be the right one for redirecting the advertised URL of a site to the URL where it's actually hosted, but it seems a number of redirection providers wrongly use 301.  (That said, I can't seem to make out by a quick read the difference between 302 and 307.)

The trouble is that, depending on the hosting provider and server software, one may or may not have the means of setting up HTTP redirection.  Meta refresh thus provides an alternative means.  However, one should not use _only_ meta refresh!  Some browsers provide a means of disabling it.  This is yet another reason (besides search engines) that you should always have a plain HTML link as a fallback.

view-source:http://www.lrca.org.uk/
or, if this doesn't work for you
http://validator.w3.org/check?uri=http://www.lrca.org.uk/&ss=1

demonstrates a three-level approach to redirection: meta refresh, JavaScript and finally a link on the page.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies on the 'group where everybody may benefit. 

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.

2. 301 is sometimes overused, because it will carry Google page rank while other 3xx codes will not.  301 is also normally cached, unlike the others which normally aren't (even if cache headers say to, most clients  and proxies ignore them.)

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), 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.

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...

-[Unknown]


Stewart Gordon wrote:
> "Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:fn891s$1ncq$1@digitalmars.com...
>> Yes, a 301 should work like that (as would 302.)
> 
> <snip top of upside-down reply>
> 
> Yes, HTTP redirection using a status code in the 300s is the best way.  But you should use the right code!
> 
> In this instance, the correct code would indeed be 301 (moved permanently). 302 (found) would probably be the right one for redirecting the advertised URL of a site to the URL where it's actually hosted, but it seems a number of redirection providers wrongly use 301.  (That said, I can't seem to make out by a quick read the difference between 302 and 307.)
> 
> The trouble is that, depending on the hosting provider and server software, one may or may not have the means of setting up HTTP redirection.  Meta refresh thus provides an alternative means.  However, one should not use _only_ meta refresh!  Some browsers provide a means of disabling it.  This is yet another reason (besides search engines) that you should always have a plain HTML link as a fallback.
> 
> view-source:http://www.lrca.org.uk/
> or, if this doesn't work for you
> http://validator.w3.org/check?uri=http://www.lrca.org.uk/&ss=1
> 
> demonstrates a three-level approach to redirection: meta refresh, JavaScript and finally a link on the page.
> 
> Stewart.
> 

"Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:fu97a9$1lgv$1@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. 

1. Yes.  In both cases, they failed.  Biz is tacky, and 307 is poorly supported.  Oh, well...

2. A page can have "page rank" in Google's eyes.  If a popular page (let's say www.amazon.com's front page) linked to your page, it would greatly increase that page's page rank.

However, if someone links to a page that is a redirection, Google has two options:
	A. If the status code is a "302" or similar, the existing page gets the increase in page rank.  The actual destination page (which is indexed) has its own separate page rank.

	B. If the status code is a "301", the existing page gets nothing, and the destination gets all the glory.

It's better to have 1 page with a really high page rank, than 10 pages with low page rank.  As such, 301's are best when the redirect is, well, permanent... where the resulting page is really the desired one.

2b. Really?  That's crazy.  Google shouldn't cache that.  I meant browsers and proxies.  It's wrong to cache the result of the 301, just the fact that it redirects (the 301 itself.)

3. Well, Refresh uses a parameter, like this: "0; http://www.google.com/".  The "0" in this case is the number of seconds after the entire page has loaded (in most browsers, after the load event has been posted.)  On the other hand, a 301/Location combination happens as soon as the browser finishes reading the headers.

3b. There is a correct syntax.  In my experience, I have seen people use the incorrect syntax.  It's the age-old problem of IE (most of the time) accepting invalid code that shouldn't and doesn't work elsewhere.

5. Yeah, that's basically my point.  I've also been told (THIS IS A RUMOR) that Google penalizes you for JavaScript redirects.  Seems silly (esp. if you used a 301 on the same page) but everything in SEO is experience, guesswork, and rumor.

Also, take a look at Minefield.  It blocks many "automatic redirects" by default.  I've had it break many sites (although you can allow the redirect easily), actually.  I think it blocks both js and meta redrects not resulting from a POST or user click/etc.

-[Unknown]


Stewart Gordon wrote:
> "Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:fu97a9$1lgv$1@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.