Small URLconf suggestion
rihad
I'm sure I'm not the only user who doesn't like the look of trailing
slashes in URLs, or more precisely, the difference in behavior that
they imply for Django users. How about simply changing this:
(r'^hello/$', hello),
to this
(r'^hello/*$', hello),
so that any number of trailing slashes are completely optional? The
APPEND_SLASH setting would then be important in very specific cases
only.
Russell Keith-Magee
I'm a little unclear as to what change you are proposing. The URLconf
is entirely under the control of the end user. If you don't like
trailing slashes, then don't use them. Django provides the
APPEND_SLASH option as a way to interpret the 'missing slash' on users
URLs, but if you set up your URLs to avoid the need for the trailing
slash, then you have no need for the APPEND_SLASH option at all.
So - what exactly are you proposing that we change in Django?
Looking at your proposal as a purely end-user suggestion: using
'hello/*$' means that hello////// will match your URL pattern.
'hello/?$' would be a safer match, as it would only match a single
trailing slash.
However, it still wouldn't be a good idea to deploy this pattern. Some
search engines (Google being a notable and prominent example) penalize
websites that post identical content on multiple different URLs, as
this is a common marker of SEO spam. Deploying hello/*? or hello/?$
means that multiple URLs will serve the same content. Problems with
trailing slashes notwithstanding, the APPEND_SLASH approach uses a
redirect, which doesn't attract the same 'Google penalty'.
Yours,
Russ Magee %-)
rihad
On Feb 22, 3:55 pm, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:
>
> Looking at your proposal as a purely end-user suggestion: using
> 'hello/*$' means that hello////// will match your URL pattern.
> 'hello/?$' would be a safer match, as it would only match a single
> trailing slash.
>
otherwise APPEND_SLASH wouldn't exist.
Moreover, hello and hello/ (and hello/////) _are_ the same URL to
Django, otherwise it wouldn't redirect to the url with the slash
appended. APPEND_SLASH looks more like a hack, so why not treat the
URLs the same from the beginning? This is all I was proposing.
> However, it still wouldn't be a good idea to deploy this pattern. Some
> search engines (Google being a notable and prominent example) penalize
> websites that post identical content on multiple different URLs, as
> this is a common marker of SEO spam. Deploying hello/*? or hello/?$
> means that multiple URLs will serve the same content. Problems with
> trailing slashes notwithstanding, the APPEND_SLASH approach uses a
> redirect, which doesn't attract the same 'Google penalty'.
>
URLs that only differ in the amount of trailing slashes (0 or more)
are the same? Too bad then.
rihad
On Feb 22, 4:44 pm, rihad <ri...@mail.ru> wrote:
> amount of trailing slashes
number of trailing slashes. Sorry for my English. ;-/
George Vilches
On Feb 22, 2009, at 7:44 AM, rihad wrote:
> I was just special-casing the backslash, which is special anyway,
> otherwise APPEND_SLASH wouldn't exist.
> Moreover, hello and hello/ (and hello/////) _are_ the same URL to
> Django, otherwise it wouldn't redirect to the url with the slash
> appended. APPEND_SLASH looks more like a hack, so why not treat the
> URLs the same from the beginning? This is all I was proposing.
This statement is wholly inaccurate. Those URLs are only the same to
Django in the case where a rule is written to accept them that way,
and the webserver above is nice about the treatment of them. Take
this example:
urlpatterns = patterns('',
(r'hello', 'view1'),
(r'hello/', 'view2'),
)
Those are most definitely the same, and this is by choice and by user
convention. I am a strong -1 to your ideas about not making slash
default, or that anything here is a /. If APPEND_SLASH was a hack,
then why does every webserver have equivalent functionality to emulate
the add a trailing / behavior?
gav
George Vilches
morning, sorry about that.
rihad
On Feb 22, 5:29 pm, George Vilches <g...@thataddress.com> wrote:
> Take this example:
>
> urlpatterns = patterns('',
> (r'hello', 'view1'),
> (r'hello/', 'view2'),
> )
>
in only the trailing slashes is, ugh, awkward. Slash shouldn't be
treated like a normal char in this regard, i.e. the difference between
r'hello' and r'hello/' isn't the same as the difference between
r'hello1' and r'hello2', at least I think so, and Django thinks so by
redirecting url to url/ when the former isn't found (subject to
APPEND_SLASH), but your opinion may be different.
> I am a strong -1 to your ideas about not making slash
> default, or that anything here is a /
instead of r'^foo/$', i.e. making trailing slashes optional (unless
Google robots penalize for that).
> Those are most definitely the same, and this is by choice and by user
> convention. I am a strong -1 to your ideas about not making slash
> default, or that anything here is a /. If APPEND_SLASH was a hack,
> then why does every webserver have equivalent functionality to emulate
> the add a trailing / behavior?
>
the last part of the path, but does Django care about FS with its
Smart URLs?
Or would one prefer opening http://example.com/user/21 and being
redirected to http://example.com/user/21/ as per default settings? At
least Chapter 3 of the online djangobook 2.0 puts / at the end of
almost all URLs, so the redirect is unavoidable.
Unless someone kindly proves me wrong, I really do think trailing
slashes in the URL should be optional, but this probably wouldn't
happen until Django 3.x
Jacob Kaplan-Moss
> Unless someone kindly proves me wrong, I really do think trailing
> slashes in the URL should be optional,
As Russ already said -- did you read his post? -- this is already *up
to you*. If you want trailing slashes to be optional:
1. Set APPEND_SLASH to False.
2. Write your urlconfs with optional slashes.
3. There is no step three.
Django itself makes no assumptions about how you'd like to design your
URLs. Behavior like APPEND_SLASH and PREPEND_WWW are shortcuts for
common desires, but both are incredibly easy to disable.
Why don't you back up a step: What are you trying to do that isn't working?
Jacob
rihad
On Feb 22, 7:47 pm, Jacob Kaplan-Moss <jacob.kaplanm...@gmail.com>
wrote:
> > Unless someone kindly proves me wrong, I really do think trailing
> > slashes in the URL should be optional,
>
> As Russ already said -- did you read his post? -- this is already *up
> to you*. If you want trailing slashes to be optional:
>
> 1. Set APPEND_SLASH to False.
> 2. Write your urlconfs with optional slashes.
> 3. There is no step three.
>
> Django itself makes no assumptions about how you'd like to design your
> URLs. Behavior like APPEND_SLASH and PREPEND_WWW are shortcuts for
> common desires, but both are incredibly easy to disable.
>
least djangobook teaches us to end all complete URLs in a slash, which
IMHO should really be optional, so that the regex matches with or
without the trailing slash(es) in the actual URL, _and_ without
incurring the HTTP round-trip through redirection. Just a suggestion,
please don't take it too harshly ;)
> Why don't you back up a step: What are you trying to do that isn't working?
Alex Gaynor
Alex
--
"I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire
"The people's good is the highest law."--Cicero
Jacob Kaplan-Moss
> Nothing, really, It was just a design suggestion.
I think that's the basic hang-up you're running into here: we don't
really do that kind of development. Every single piece of code in
Django exists because someone -- often lots of people -- have a
concrete problem in a real-world application. We don't write code
speculatively, nor do we care to spend a lot of time debating style.
Trailing slashes versus non-trailing is a design issue, and as long as
Django's allowing both styles you're not going to get a lot of
traction suggesting that Django somehow "solve" the question.
Jacob
rihad
consider for the future.