now APPEND_SLASH works like this: for any URL which doesn't end with a
slash, and whose last segment doesn't contain a dot "." (the dot which
typically indicates the file extension), an HTTP-redirect is generated
to an URL formed from the initial URL with a slash appended.
I'd like to propose an alternative way of handling the 'end-slash'
problem, like this:
If the initial URL doesn't end with a slash, and it is not found in
urlpatterns, a new URL is formed by appending a slash at the end. If
this new URL is found in urlpatterns, then an HTTP-redirect is returned
to this new URL; otherwise the initial URL is processed as usual.
This behavior emulates the serving of filesystem-based files and
directories, where a request for a directory without slash at the end
results in a redirect with the slash appended; but a request for a file
(regardless whether the file has a dot or not) doesn't append a slash.
I consider this way of handling the end-slash to be a better
altervative over the two choices that exist now (APPEND_SLASH=True or
APPEND_SLASH=False), as it somehow merges together these two modes. It
also handles uniformilly URLs that have or don't have a dot in the last
segment, which is good.
Cheers,
Mihai Preda
Hm. My first impression is that I like it, mostly for the reasons
you've outlined; I had to turn off APPEND_SLASH when I decided I
didn't want trailing slashes on individual entries on my weblog,
because it would add them regardless of whether the slash-less URL
matched anything.
I also like that you've suggested not doing the redirect unless the
"slashified" URL would actually match something; being able to just
404 immediately on something that won't match is nice.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
A couple of minor refactorings which are needed by this class are in
ticket #3224.
I hope somebody can review these patches, and commit them after
eventual fixes.