Closed Bug 670316 Opened 15 years ago Closed 15 years ago

Determine how to handle namespace URLs

Categories

(www.mozilla.org :: General, defect)

Product:
www.mozilla.org
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: GPHemsley, Unassigned)

References

Details

Attachments

(1 file, 1 obsolete file)

Use mod_rewrite to prevent 404 errors on XML namespace URIs (v2)
4.26 KB, patch
GPHemsley
: review+
Details | Diff | Splinter Review
We have a number of namespace URLs that are turning up 404 errors. We should probably figure out how to handle these. Perhaps we want to create pages for each, or just redirect all namespaces (or the remaining, if some have custom pages) to a single page. It has been suggested that redirecting the URLs would break things. We should determine if that is true and how that affects our solution.
I'm confused, by "namespaces" do you mean subdir's of http[s]://www.mozilla.org or some sort of wiki. If wiki, which: * wiki.mozilla.org * support.mozilla.org * intranet.mozilla.org * developer.mozilla.org * Other?
(In reply to comment #1) > I'm confused, by "namespaces" do you mean subdir's of > http[s]://www.mozilla.org > > or some sort of wiki. > > If wiki, which: > * wiki.mozilla.org > * support.mozilla.org > * intranet.mozilla.org > * developer.mozilla.org > * Other? See the blocking bugs for more information. I believe they are all XML namespace URLs.
The spec (<http://www.w3.org/TR/xml-names/#NSNameComparison>) makes it pretty clear that redirecting would be fine, IMO. I would suggest either redirecting to an appropriate MDN page, or serving a page with a link to that MDN page.
I think we should just WONTFIX them. XML namespaces look like URLs but nothing requires them to be existent documents.
(In reply to comment #4) > I think we should just WONTFIX them. XML namespaces look like URLs but > nothing requires them to be existent documents. I'm leaning this direction too. Other than the fact that we get some 404 bugs filed about these, there doesn't seem to be any demand to have pages at those locations.
(In reply to comment #5) > (In reply to comment #4) > > I think we should just WONTFIX them. XML namespaces look like URLs but > > nothing requires them to be existent documents. > > I'm leaning this direction too. Other than the fact that we get some 404 > bugs filed about these, there doesn't seem to be any demand to have pages at > those locations. I don't know... I'm not comfortable leaving 404s for URLs that we know are out in the wild. At the very least, we could redirect them all to a single page that says "This is an XML namespace URI". But I think comment 3 details the ideal solution: redirect them to their respective pages on MDN.
> At the very least, we could redirect them all to a single page that says > "This is an XML namespace URI". We should check with relevant people for each namespace first before we do that since concerns have been raised in the past about redirecting those links.
For reference, bug 454831 is from a couple years ago that discusses this topic.
(In reply to comment #8) > For reference, bug 454831 is from a couple years ago that discusses this > topic. Heh. That's funny. So the concern with redirecting was what the actual namespace was. Except a big deal was made about the fact that namespace URIs are not required to be URLs. So no one (except curious humans) should be attempting to load them. Thus, there is no real problem with redirects. (If the curious humans get confused as to what URI to use as the namespace, there should be one or more relevant documents on the target page of the redirect to help them sort that out.) Given that this issue has come up in the past and will likely continue to come up if we try to ignore it, we may as well do something about it. It would probably take much less effort. That said, to alleviate confusion for those curious humans, perhaps we should follow the proposal given in bug 454831 comment 3 (reiterated in the other half of comment 3 here) of just having a barebones page that then has a link to the MDN page.
Depends on: 454831
(In reply to comment #9) > That said, to alleviate confusion for those curious humans, perhaps we > should follow the proposal given in bug 454831 comment 3 (reiterated in the > other half of comment 3 here) of just having a barebones page that then has > a link to the MDN page. I'm not opposed to this but would like to see a clear demand for this from people creating and using the namespaces. Given that I'm in the mindset of reducing the number of pages and directories on the site, I want a good reason to start adding a bunch more new pages and directories :)
(In reply to comment #10) > Given that I'm in the mindset of reducing the number of pages and > directories on the site, I want a good reason to start adding a bunch more > new pages and directories :) Ah, but the beauty of mod_rewrite means that we need only add a single additional file! See the attachment.
Attachment #545050 - Flags: review?(paul)
Attachment #545050 - Flags: review?(dboswell)
> (In reply to comment #11) > Ah, but the beauty of mod_rewrite means that we need only add a single > additional file! I like that. > Created attachment 545050 [details] [diff] [review] [review] > Create namespace pages using mod_rewrite Couple of comments: * Is it possible to put this in an existing directory? Maybe in /script? * There's already an XML file for the XUL namespace. Are you suggesting removing that in favor of this or do we not need to include that in here?
BTW, if we're keeping the XUL namespace page we need to fix it so it shows up in new Firefoxes -- bug 664260.
(In reply to comment #12) > * Is it possible to put this in an existing directory? Maybe in /script? Sure, we can put it anywhere. That's part of the beauty! > * There's already an XML file for the XUL namespace. Are you suggesting > removing that in favor of this or do we not need to include that in here? (In reply to comment #13) > BTW, if we're keeping the XUL namespace page we need to fix it so it shows > up in new Firefoxes -- bug 664260. Right, that was part of the reason I included XUL in this file (aside from the fact that it was held as the quintessential example of a namespace that has a page). The XUL namespace page is written in, well, XUL. The problem with that is that remote XUL (accessed via the Web instead of inside the browser) is no longer supported, for security reasons. Rewriting it in regular XML would probably be a lot more hassle than just moving it into this one-stop script that outputs HTML. In doing so, I've tried to keep the spirit the same. :)
OK, that all sounds good to me. To confirm, if we move the XUL namespace note into here we can remove the keymaster directory?
(In reply to comment #15) > OK, that all sounds good to me. To confirm, if we move the XUL namespace > note into here we can remove the keymaster directory? If that's the only reason it's sticking around, then yes. So where do you want the namespace.php file? In /script/?
No longer blocks: 645287
Blocks: 549301
Blocks: 519042
(In reply to comment #16) > If that's the only reason it's sticking around, then yes. I think so. I'll double check before removing anything. > So where do you want the namespace.php file? In /script/? Yes, please.
This is the patch I've committed to staging in r92378. It moves the namespace.php file to /scripts/ and adds support for Add-ons Blacklisting (bug 519042). Paul, I'll wait on your review before I push it to trunk.
Attachment #545050 - Attachment is obsolete: true
Attachment #545116 - Flags: review?(paul)
Attachment #545050 - Flags: review?(paul)
Attachment #545050 - Flags: review?(dboswell)
(In reply to comment #13) > BTW, if we're keeping the XUL namespace page we need to fix it so it shows > up in new Firefoxes -- bug 664260. The XUL namespace is its own case and I think we should not remove it unless we eliminate XUL and 80% of our active community. Let's leave it to its own bug, please. Those that never had a document are what we should handle here.
(In reply to comment #19) > (In reply to comment #13) > > BTW, if we're keeping the XUL namespace page we need to fix it so it shows > > up in new Firefoxes -- bug 664260. > > The XUL namespace is its own case and I think we should not remove it unless > we eliminate XUL and 80% of our active community. Let's leave it to its own > bug, please. > > Those that never had a document are what we should handle here. As noted in the subsequent comments, we are not removing the XUL namespace. As it stands now, it is not even viewable in current versions of Firefox. By including it under the auspices of this script, we allow it to once again be useful. Compare: http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul to: http://www-stage.mozilla.org/keymaster/gatekeeper/there.is.only.xul (And do it quickly, because the difference will only exist before Paul reviews the patch I committed to stage.)
(In reply to comment #20) > http://www-stage.mozilla.org/keymaster/gatekeeper/there.is.only.xul That's so boring compared to the original - and still a different bug it belongs in.
Attachment #545116 - Flags: review?(jlong)
Committed change to trunk in r93477 with r=jlongster. It should go live soon, so resolving this as FIXED. Robert, if you feel that the XUL namespace should not be incorporated into this script, please file a new bug. In the meantime, this is better than the status quo. David, I believe you are free to delete the keymaster/ directory now.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Attachment #545116 - Flags: review?(paul)
Attachment #545116 - Flags: review?(jlong)
Attachment #545116 - Flags: review+
Blocks: 664260
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: