On Wed, Nov 19, 2008 at 9:07 PM, Jorge Vargas <[EMAIL PROTECTED]> wrote:
>
> On Wed, Nov 19, 2008 at 2:43 PM, Randy Syring <[EMAIL PROTECTED]> wrote:
>>
>>
>> On Nov 19, 2:20 pm, "Raoul Snyman" <[EMAIL PROTECTED]> wrote:
>>> On Wed, Nov 19, 2008 at 7:05 PM, Mike Orr <[EMAIL PROTECTED]> wrote:
>>> > Looking at your modules, I didn't know Routes had an .append_slash
>>> > option but that could be throwing it off. There's no reason to put
>>> > slashes at the end of URLs except to make it look like a directory to
>>> > the user, but even then it's not necessary (/messages and
>>> > /messages/1234 work fine).
>>>
>>> I prefer ending urls with / :-D
>>
>> This is somewhat off topic, but I used to prefer the above too. Then
>> I had a page referenced by that type of URL that needed query string
>> arguments. I ended up with a URL like this:
>>
>> example.com/this/page/?foo=bar
>>
>> Having the whole "/?" thing just killed this idea for me. Now all my
>> routes specifically do not end in a slash. Anyone else have thoughts
>> on this?
>>
> I don't remember where I read it but URLs ending with / are supposed
> to be directories so the above behavior is wrong for webapps.
Say you have a static server like this:
/dir/
index.html
other.html
The user requests "/dir/index.html", which contains a link to
"other.html". The base URL is "/dir/", so the browser does a join and
comes up with "/dir/other.html".
Or the user requests "/dir/". The server assumes the default
document, index.html. Again the base URL is "/dir/", and the relative
link resolves to "/dir/other.html".
Or the user requests "/dir". This ends in a directory so the server
issues a redirect to "/dir/", and then serves the default document.
The base URL and resolved link are the same.
If the server didn't issue a redirect but served index.html directly,
the base URL would be "/dir". The browser wouldn't know this is a
directory so it assumes "dir" is the current document and drops it
before joining:
"/dir" - "dir" + "/other.html" => "/other.html"
which is the wrong URL and doesn't exist.
In a non directory-based framework like Pylons, the choice of what to
serve for "/foo", "/foo/", and "/foo/bar" are arbitrary. Pylons can't
automatically redirect "/foo" because it doesn't know it's supposed to
be a directory. It can't divine that "/foo/bar" exists and
"/foo/NONEXISTENT" doesn't, because that's only known when those URLs
are requested. So, you have a choice:
1) Serve "/foo" as a container and let "/foo/" not exist, which is
what most Pylons apps do.
2) Redirect "/foo" to "/foo/".
3) Serve identical content for "/foo" and "/foo/".
4) Serve different content for "/foo" and "/foo/".
The trouble with #4 is thinking up a practical case for it. When do
you need two slightly different indexes? Perhaps a title page and a
table of contents. But nobody does it that way, and it's prone to
human misperception or browser misperception given the precendent of
static files.
The corollary is that relative URLs don't work with the default Pylons
case. You may be able to get from "/foo/bar" to "/foo/baz" with a
link to "baz", and if you're lucky you might be able to get to
"/foo/index" with "./", or "/foo" with "..", but it depends on your
routing. This is one reason why Pylons (and TurboGears and Rails)
discourage relative URLs in favor of url_for(), which generates a
fully-qualified, unambiguous URL.
Another aspect is that users don't like to type trailing slashes.
They also don't know whether something is a container, so they'll type
"http://example.com/articles"; because somebody told them there's an
articles URL.
--
Mike Orr <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
