The proper URI is: http://www.mozilla.org/start/ Not: http://www.mozilla.org/start Fixing this will help alleviate some server load as it avoids a redirect on requesting the current URI. And every little bit surely helps during a release...
Comment on attachment 82622 [details] [diff] [review] Simple patch v.1.0 r=mpt (with the usual complaint that this page should be redundant with <http://mozilla.org/> but isn't)
I'm pretty sure this is wontfix. Someone already asked about this before and gerv said the http://www.mozilla.org/start is correct
Okay, I am told that this is bug 101206 which Gerv verified as WONTFIX. The reasoning there is: >In the new website world, where content type extensions such as .html no longer >exist, this may well be a top-level object simply called "start". However, the new website world isn't so new. In fact its pretty damn old because that post was made on Sep. 23, 2001. Nigh on 8 months ago and there still is no new website world. Gerv, I urge you to take this fix for a few reasons (and I see that bug 141718 needs an adjustment too so I urge a fix there for /start/1.0/ which I will provide a patch for pending your comments) 1. Server load is going to an issue now more than ever with 1.0 looming on the horizon. This will not cure every load issue, but it will definitely help. 2. If Mozilla.org feels it is "okay" for server redirects to occur, why then would it not be feasible to redirect mozilla.org/start/ to mozilla.org/start when this "new website world" becomes reality? 3. In addition, in the new website world where content type extensions such as .html no longer exist, why couldn't this be included in the directory? To suggest that in the "ideal" world we can only have enough documentation on "how to start getting involved" to just fill one top level page is insane. We should be able to put together several pages which can concievably and logically exist underneath the "start/" folder. 4. If the brave new world is not on the horizon as appears to be, please let's stop worrying about the future and worry about now. This is an issue now. When we reach the new site in the future, we can then adjust any existing URIs within the browser to whatever the need may call for at that point. Those on new browsers will go directly to the "brave new page", and those on older browsers can still be redirected. Gerv, though I could easily "sneak this in" with a quick sr=, I will clear the review from others and seek your review first. I am leaving this bug open rather than re-opening the existing bug because there is a patch here, and because I own this bug.
Status: NEW → ASSIGNED
Comment on attachment 82622 [details] [diff] [review] Simple patch v.1.0 Clearing review as promised (no offense to mpt or brad, there's just no other way to say I need gerv's review)
Also note that NOW, the redirect applies to everyone who uses Mozilla. If we accept this patch, then nobody is redirected for the time being. When (and if?) the new website comes and we change the Moz source to link to whatever page we do decide to use, the redirect that we would put in place then will only apply to people who install old builds, or are on an existing old build without yet changing their homepage. I'm pretty confident in saying that most people change their homepage almost immediately. So the redirect would be lesser impact in the future than it is now. I do understand the reasoning for leaving off the trailing slash. I just don't buy it...
It looks like the patch will break rpm's. I think you need to update the home-page-patch files as well. mozilla/build/package/rpm/SOURCES/mozilla-redhat-home-page.patch mozilla/build/package/rpm/SOURCES/mozilla-redhat-home-page-6.2.patch http://lxr.mozilla.org/seamonkey/search/search?string=mozilla.org%2Fstart Please also fix the "/start/1.0" links on the branch.
Sorry for the spam, but it'd be nice to actually evaluate if this page (/start) is hit a lot on mozilla.org and, for this, the stats tool would help, see bug 105914.
> r=mpt mpt, I thought you told me (and this was the rationale behind http://mozilla.org being an alias) that URLs should be as short as possible while still working? :-) > However, the new website world isn't so new. In fact its pretty damn old > because that post was made on Sep. 23, 2001. Nigh on 8 months ago and there > still is no new website world. All help gratefully accepted :-) But this doesn't invalidate the point. > 1. Server load is going to an issue now more than ever with 1.0 looming on the > horizon. This will not cure every load issue, but it will definitely help. The effect will be too small to be noticeable. By now, we must serve well over half a million hits a day (although webstats have been broken for a while, pending the insertion of a four-line patch, so I can't tell) and the effort the webserver spends on this is negligible. > 2. If Mozilla.org feels it is "okay" for server redirects to occur, why then > would it not be feasible to redirect mozilla.org/start/ to mozilla.org/start > when this "new website world" becomes reality? Because in the new world, redirects are represented by objects in the filesystem, and having them hanging around is ugly. > To suggest that in the "ideal" world we can only have enough documentation on > "how to start getting involved" to just fill one top level page is insane. Getting involved information will not live under this branch of the website tree (according to the layout we decided on.) I don't have the URL to hand - ask firstname.lastname@example.org for a copy. Anyway, the slashless version gives you a choice of a directory or an object - the slashed version restricts you to a directory. For goodness sake, people, there are _so_ many more productive things to do with your lives than worry about this. The amount of energy that's been expended on this bug already could have achieved really useful things elsewhere (like on the new website.) Do you really feel so powerless to help with other Mozilla stuff that you are reduced to "fixing" things like this? That would be depressing. Gerv
I'm sorry, I thought this was such an "obvious" error that I didn't bother to even list the original reason I noticed this bug. I was on a 28.8 connection yesterday while installing Mozilla on a computer for a friend. It took a few seconds just to connect to <http://www.mozilla.org/start> and then a few extra seconds just to connect to <http://www.mozilla.org/start/>. The re-direct wasted maybe 2-3 seconds of her initial startup Page load time by trying to connect to something that wasn't there. Shall I call the perf gurus in on this bug to tell you that time is unacceptable? > For goodness sake, people, there are _so_ many more productive things to do with your lives than worry about this. Gerv, so then go ahead and worry about them and let me fix this bug. It is obviously an issue. Unfortunately all the many people who agreed with me last night resigned to the fact that if someone @mozilla.org made a decision, they are automatically correct and had no intention of disputing it. I don't resign so easily, though. > Because in the new world, redirects are represented by objects in the filesystem, and having them hanging around is ugly. Yes, redirects are ugly. That's exactly my point! Let's get rid of the redirect NOW. But are you getting rid of Apache? Why could you not just set up a redirect via the server instead of some "object" which you're being cryptic about. Gerv, please read http://www.mozilla.org/README-style.html for our *own* guidelines which you appear to not care about. At the present time, the URL is a directory. When that state changes to whatever object you have planned, let us worry about how to go to the object (changing links in the browser and setting up a temporary redirect should work, shouldn't it?) Endico, thanks for pointing that out. I'll update those files as well with the patch.
We're doing whatever is right for the current site. Forward compatability with a site framework that has not even been evaluated, much less adopted, is not critical here. We should do what works best for the current state and we should do this quickly.
never mind. re: patching the rpm patch files, blizzard says "don't worry about it". He has to change those files regularly anyway. Could you do the patch for the branch first so we can get it in for rc2? thanks.
Comment on attachment 82680 [details] [diff] [review] Patch for the 1.0 branch only because caillon included the style url which contains: Don't point to index.html directly. When linking to pages, point to the directory rather than the index.html file. When linking to a directory, include the trailing slash in the URL. That is, <A HREF="foobar/"> is good, <A HREF="foobar/index.html"> is bad, <A HREF="foobar"> is bad.
Attachment #82680 - Flags: review+
Comment on attachment 82680 [details] [diff] [review] Patch for the 1.0 branch I'm going to sr this for the branch (sr=shaver, done), though I wonder why we don't do an internal redirect for start to start/ anyway. Ah well. Thanks, Chris. When we get the new web site, we can solve this problem for all the old directories with the same system.
Attachment #82680 - Flags: superreview+
<sigh> Whatever, then. I just wish there were as much consensus about, and as much effort put behind, bugs which really matter. Gerv
Comment on attachment 82680 [details] [diff] [review] Patch for the 1.0 branch a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #82680 - Flags: approval+
Checked in on the branch.
Comment on attachment 82680 [details] [diff] [review] Patch for the 1.0 branch (checked in already)
Attachment #82680 - Attachment is obsolete: true
Comment on attachment 82622 [details] [diff] [review] Simple patch v.1.0 Way back in comment #2, mpt gave r= so I'm re-adding this and I'll seek sr= tomorrow.
Comment on attachment 82622 [details] [diff] [review] Simple patch v.1.0 jag says rs=jag
Attachment #82622 - Flags: superreview+
Checked in on the trunk. Resolving fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.