On Fri, 2005-07-08 at 22:40 +0100, Timwi wrote:
Rob Lanphier wrote:
On Fri, 2005-07-08 at 20:56 +0100, Timwi wrote:
Article titles with a slash in them, such as
[[History/edit]] if anyone
ever wanted to create it, could be encoded using a double-slash:
http://en.wikipedia.org/History//edit
http://en.wikipedia.org/History//edit/edit
http://en.wikipedia.org/History//edit/history
This is less alienating than "%28" for parentheses or "%2C" for
commas,
but of course one could always use "%2F" for slashes for consistency.
I'm not sure if there's a specific prohibition of this practice in any
spec,
No, there isn't.
Ok, that's good. What about the ramifications for relative URL handling
in RFC 2396?
http://www.ietf.org/rfc/rfc2396
I haven't found any immediate problems, but it would take me a while
reading through the BNF to figure out if there are places where it
breaks.
Not that it's a huge deal if relative URLs don't work, since MW can
always just stick to absolute references, but its one area where things
can go wrong.
but it does
fight typical conventions, which is kind of a bad
thing. For example, it appears that Apache throws away extra slashes,
as can be seen here:
http://apache.org///foundation////faq.html
http://apache.org/foundation/faq.html
IIS seems to do the same thing:
http://www.microsoft.com////windowsserversystem///default.mspx
I assure you that Apache does not throw away extra slashes. I have
already done the necessary programming to do URLs such as those I have
mentioned. The examples you mentioned don't say anything about the
webservers themselves because both URLs are obviously mappings to a
filesystem (whether virtual or not); it is that filesystem that throws
away the extra slashes (which you can easily test: Both Linux and
Windows allow you to put double-/ resp. double-\ in a path and it won't
complain).
Compare:
http://www.livejournal.com/manage/index.bml
and
http://www.livejournal.com/manage//index.bml
They show the same page because the path is a mapping to a filesystem,
but the pages are different because the individual strings on it are
retrieved from codes that are based on the path. Those codes contain
only single slashes, so the second page is missing those strings. This
clearly shows that it's the filesystem and not Apache that "throws away"
double-slashes.
Ok, that's good.
Still, I maintain that assigning unique semantics to "//" versus "/"
when used in that part of a URL doesn't have a lot of precedent, which
also means that there's probably a lot of places it can break. I admit
that's a vague criticism, but I just have a bad gut feeling about going
down that road.
Mixing
subpages into the action namespace seems like a bad idea.
Arguably its worse when its only the exception, because that means it'll
be something that will always need to be accommodated, but rare enough
that its often forgotten.
I don't understand what you're saying here. I'm not "mixing"
anything.
The rest doesn't seem to make any sense. Can you rephrase this?
First, let me quote again the part of your proposal which I was
responding to, and try again with a clearer response:
URLs such as
http://en.wikipedia.org/Pagename/subpage
would then redirect to
http://en.wikipedia.org/Pagename//subpage
and you could still type a single slash as long as the subpage doesn't
happen to be "edit", "history", or any of the other magic words.
Let's say there's an article called "Particles", with a sub-article
"Atom".
The "Particle" article would be:
http://en.wikipedia.org/Particles
...and the Atom subarticle would be:
http://en.wikipedia.org/Particles/Atom
Now lets say that a future version of MW allows output of the history of
any page in Atom form, with "/Atom" designating the output.
So, after the upgrade, what used to be a valid reference to the Atom
article is now an atom feed. The new URL to the article is:
http://en.wikipedia.org/Particles//Atom
But wait, we already committed to not break incoming links. Crap...now
we have to choose a name for every new action that doesn't overlap with
any existing subpage.
This is what I mean about keeping namespaces separate ("namespace" in
the general sense, not the MediaWiki specific "Foo:Bar" sense). I would
much prefer there be a syntactic way of distinguishing between a subpage
and an action that always works, even on Tuesdays ;-)
Of course it would "work", but it's not what I want because
"?action="
is a pain to type.
...but it's far less ambiguous, and it's clear that it's an action
performed on article "Pagename", rather than a page of its own.
Rob