Re: append_slash alternative: remove_slash
On 16 Jun., 15:05, Luke Plant wrote: > On Sunday 14 June 2009 06:12:32 donquixote wrote: > > > Nice (i): > >http://mysite.org/members/emil > >http://mysite.org/members/emil/contact > > > Not nice (ii): > >http://mysite.org/members/emil/ > >http://mysite.org/members/emil/contact/ > > You have some problems: > > 1) All contrib apps, and many others, put a slash at end of the URL > conf regexes. This means that without APPEND_SLASH = True, you will > get 404s for e.g. /admin/foo which is not very friendly behaviour. This problem is taken care of in my original proposal. The regex will be checked with two versions of the given url. The other problem (relative links) would have to be solved with a tag. The remaining problem will be that links in the contrib apps will still have the slash (unless there is some magic to remove it), so you would get a redirect to the no-slash version. > > 2) Having more than one convention is not going to be popular - > especially as django apps are often designed to be pluggable. > Inconsistency here would be a pain in neck True. > > 3) Changing these existing apps to make the trailing slash optional > would be a *very* big task, especially when you use relative URLs like > href="../../somewhere/else/". If the current URL doesn't have a > trailing slash, then those relative URLs will be broken. In theory, > this should be fixed by use URL reversing correctly, but there isn't > even a fully capable solution in trunk yet (I believe the current > status is some design decisions need to be made with regards to the > case where you have multiple instances of the same app, I might be > wrong). Anyway, there are *many* instances of relative URLs still in > the Django code base. And I think it affects CSS too (which is not so > easily addressed as template or Python code). If it's actually necessary to do this, then you are right. > > Seeing as some people actually prefer the trailing slash, I think it > is fair to say that you are fighting a losing battle. > > Luke > > -- > "If we could just get everyone to close their eyes and visualise world > peace for an hour, imagine how serene and quiet it would be until the > looting started" -- Anon > > Luke Plant ||http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
Am 18.06.2009 um 14:35 schrieb Luke Plant: > > On Thursday 18 June 2009 01:03:15 Waylan Limberg wrote: > >> And that's really what this whole discussion is all about - >> making the developer who chooses the url scheme feel good about it. >> The fact is, whether the url I'm told over the phone should have a >> slash at the end or not doesn't matter - it will lead me to the >> page I want whether I type that ending slash or not (at least >> through a redirect). Should Django support either choice by the >> site dev? Perhaps. Does it really matter though? Not really. Which >> is probably why the core devs have been completely silent on this >> issue. > > I think you've got it exactly Waylan. Especially if you have a look at this video[1] asking people on the street what they think a browser is. Given those responses I guess it's safe to assume 99.99% of your users won't even _know_ (much less care) what a URL is. Bye Ulrich [1] http://www.youtube.com/watch?v=o4MwTvtyrUQ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
On Thursday 18 June 2009 01:03:15 Waylan Limberg wrote: > And that's really what this whole discussion is all about - > making the developer who chooses the url scheme feel good about it. > The fact is, whether the url I'm told over the phone should have a > slash at the end or not doesn't matter - it will lead me to the > page I want whether I type that ending slash or not (at least > through a redirect). Should Django support either choice by the > site dev? Perhaps. Does it really matter though? Not really. Which > is probably why the core devs have been completely silent on this > issue. I think you've got it exactly Waylan. I probably count as a core dev (not very active at the moment), and I did actually reply in the thread. It seems to have been overlooked, so here's what I wrote again: <<< 1) All contrib apps, and many others, put a slash at end of the URL conf regexes. This means that without APPEND_SLASH = True, you will get 404s for e.g. /admin/foo which is not very friendly behaviour. 2) Having more than one convention is not going to be popular - especially as django apps are often designed to be pluggable. Inconsistency here would be a pain in neck. 3) Changing these existing apps to make the trailing slash optional would be a very big task, especially when you use relative URLs like href="../../somewhere/else/". If the current URL doesn't have a trailing slash, then those relative URLs will be broken. In theory, this should be fixed by use URL reversing correctly, but there isn't even a fully capable solution in trunk yet (I believe the current status is some design decisions need to be made with regards to the case where you have multiple instances of the same app, I might be wrong). Anyway, there are many instances of relative URLs still in the Django code base. And I think it affects CSS too (which is not so easily addressed as template or Python code). Seeing as some people actually prefer the trailing slash, I think it is fair to say that you are fighting a losing battle. >>> Using the tag for point 3) is actually not a very nice solution because it requires effort (and quite a lot when you think about it in the general case - extra blocks for the header etc.), and going with what we have already does not require any effort. Regards, Luke -- Environmentalists are much too concerned with planet earth. Their geocentric attitude prevents them from seeing the greater picture -- lots of planets are much worse off than earth is. Luke Plant || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
Graham Dumpleton wrote: > I was only commenting in relation to how Apache works and the > conjecture that: > > Yep, I assumed so - just wanted to make sure that nobody read it in a more general way. > Take it as you will as being irrelevant to the main conversation about > Django itself, but am just clarifying what is reality for Apache in > relation to that sweeping statement about what happened back in the > """days when all web pages were a collection of static html files""". > For users, the original statement ( /foo, /foo/ and /foo/index.html usually being equivalent ) was correct. I think you're probably just looking at it from a different angle. As someone else pointed out, it's very likely moot at this point anyway. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
On Jun 18, 12:24 pm, Nick Phillips wrote: > Graham Dumpleton wrote: > >>> It's better to see it this way: Every page is an individual piece of > >>> content for itself, and still every page can have subpages. > > >>> A directory, on the other hand, can have subpages, but is not that > >>> interesting for itself. Which we don't want to happen - we want all > >>> our pages to be interesting! > > >> Think back to the days when all web pages were a collection of static > >> html files. Every directory within the server root had an index page > >> (usually index.html). That page could be found at any of the three > >> urls: `/path/to/dir`, `/path/to/dir/`, or `/path/to/dir/index.html`. > > > My understanding is that the default behaviour of Apache has always > > been that when '/path/to/dir' was used, it would redirect the client > > to '/path/to/dir/'. > > > It only became possible to override this from Apache 2.0 onwards. See: > > > http://httpd.apache.org/docs/2.2/mod/mod_dir.html#directoryslash > > > Disabling need for trailing slash in Apache apparently has some > > security implications as documented in that page and so in some > > respects it is discouraged. > > Two points: > > 1) Slashes were only added to directories; we're not talking about > directories in this case; > 2) Since we're not talking about that situation (i.e. a request for a > directory, which could be handled by generating an index in one of two > different ways), there are absolutely no security implications involved > in the decision (or lack of decision ;-) ) that is currently being > discussed. I was only commenting in relation to how Apache works and the conjecture that: """ Every directory within the server root had an index page (usually index.html). That page could be found at any of the three urls: `/path/to/dir`, `/path/to/dir/`, or `/path/to/dir/index.html`. """ So, sorry, but that statement is wrong as I pointed out in relation to Apache and static file serving. If you follow the link to the Apache document I referenced, you will see that the Apache documentation states: """ Security Warning Turning off the trailing slash redirect may result in an information disclosure. Consider a situation where mod_autoindex is active (Options +Indexes) and DirectoryIndex is set to a valid resource (say, index.html) and there's no other special handler defined for that URL. In this case a request with a trailing slash would show the index.html file. But a request without trailing slash would list the directory contents. """ Take it as you will as being irrelevant to the main conversation about Django itself, but am just clarifying what is reality for Apache in relation to that sweeping statement about what happened back in the """days when all web pages were a collection of static html files""". Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
Graham Dumpleton wrote: >>> It's better to see it this way: Every page is an individual piece of >>> content for itself, and still every page can have subpages. >>> >>> A directory, on the other hand, can have subpages, but is not that >>> interesting for itself. Which we don't want to happen - we want all >>> our pages to be interesting! >>> >> Think back to the days when all web pages were a collection of static >> html files. Every directory within the server root had an index page >> (usually index.html). That page could be found at any of the three >> urls: `/path/to/dir`, `/path/to/dir/`, or `/path/to/dir/index.html`. >> > > My understanding is that the default behaviour of Apache has always > been that when '/path/to/dir' was used, it would redirect the client > to '/path/to/dir/'. > > It only became possible to override this from Apache 2.0 onwards. See: > > http://httpd.apache.org/docs/2.2/mod/mod_dir.html#directoryslash > > Disabling need for trailing slash in Apache apparently has some > security implications as documented in that page and so in some > respects it is discouraged. > Two points: 1) Slashes were only added to directories; we're not talking about directories in this case; 2) Since we're not talking about that situation (i.e. a request for a directory, which could be handled by generating an index in one of two different ways), there are absolutely no security implications involved in the decision (or lack of decision ;-) ) that is currently being discussed. FWIW, I personally dislike extraneous slashes. Django views seem to me to be analogous to files, not directories, so I don't like seeing URLs that make them look like directories. Analogies can of course be taken too far. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
On Jun 18, 10:03 am, Waylan Limberg wrote: > On Wed, Jun 17, 2009 at 6:19 PM, donquixote wrote: > > > On 17 Jun., 03:14, Graham Dumpleton > > wrote: > >> On Jun 17, 10:04 am, donquixote wrote: > > >> > I would still be interested to read some arguments in favour of the > >> > trailing slash. From a user perspective, it seems that without is > >> > better. > > >> The big issue with trailing slash, is that you should use a trailing > >> slash on a URL which represents an internal node in the URL tree which > >> can have sub nodes and which is intended to represent some > >> conglomerated view or directory listing onto those sub nodes. One can > >> probably leave it off where URL represents a leaf node of the tree, > >> just not the internal nodes. > > > I don't think this fits the mental models people usually have of > > websites. "This is a listing with child nodes" vs "This is a single > > node." And even then, a single node can have sub-pages - for instance, > > a page showing a user profile can have a subpage user/graham/blog. > > > It's better to see it this way: Every page is an individual piece of > > content for itself, and still every page can have subpages. > > > A directory, on the other hand, can have subpages, but is not that > > interesting for itself. Which we don't want to happen - we want all > > our pages to be interesting! > > Think back to the days when all web pages were a collection of static > html files. Every directory within the server root had an index page > (usually index.html). That page could be found at any of the three > urls: `/path/to/dir`, `/path/to/dir/`, or `/path/to/dir/index.html`. My understanding is that the default behaviour of Apache has always been that when '/path/to/dir' was used, it would redirect the client to '/path/to/dir/'. It only became possible to override this from Apache 2.0 onwards. See: http://httpd.apache.org/docs/2.2/mod/mod_dir.html#directoryslash Disabling need for trailing slash in Apache apparently has some security implications as documented in that page and so in some respects it is discouraged. Graham > Obviously, not optimal. However, the recommendation was that the site > author always link to such pages consistently so that only one of > those urls would ever be used publicly. I think that's the "mental > model" Graham is talking about. As crazy as it sound, I recall seeing > someone who didn't like file extensions set up their site so that > every single page was an index page -- that is every single page was > in it's own directory, which may or may not have children. To easily > tell if a page had children or not, a slash was always used by the > author for pages that did and not for pages that did not. > > Granted, the author and a few other dev types who he told about it are > probably the only people who ever noticed, but it made him feel > better. And that's really what this whole discussion is all about - > making the developer who chooses the url scheme feel good about it. > The fact is, whether the url I'm told over the phone should have a > slash at the end or not doesn't matter - it will lead me to the page I > want whether I type that ending slash or not (at least through a > redirect). Should Django support either choice by the site dev? > Perhaps. Does it really matter though? Not really. Which is probably > why the core devs have been completely silent on this issue. > > If it hasn't happened already, file a bug as a "nice-to-have" feature > request, come up with the least invasive patch and wait for Django to > get out of feature freeze status (it is currently for the upcoming 1.1 > release - bug fixes only right now) and bring it up during the next > proposal phase if it matters that much to you. > > I don't mean to be dismissive of something some of you obvious care a > lot about, but this discussion has gone on endlessly and hasn't really > gone anywhere. And for the record, no, I'm not anyone important and > don't have any inside info on the core devs opinion, but I've seen > their silence before, and given Django current state (feature freeze), > well... there minds are focused elsewhere. > > -- > > \X/ /-\ `/ |_ /-\ |\| > Waylan Limberg --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
On Wed, Jun 17, 2009 at 6:19 PM, donquixote wrote: > > On 17 Jun., 03:14, Graham Dumpleton > wrote: >> On Jun 17, 10:04 am, donquixote wrote: >> >> > I would still be interested to read some arguments in favour of the >> > trailing slash. From a user perspective, it seems that without is >> > better. >> >> The big issue with trailing slash, is that you should use a trailing >> slash on a URL which represents an internal node in the URL tree which >> can have sub nodes and which is intended to represent some >> conglomerated view or directory listing onto those sub nodes. One can >> probably leave it off where URL represents a leaf node of the tree, >> just not the internal nodes. > > I don't think this fits the mental models people usually have of > websites. "This is a listing with child nodes" vs "This is a single > node." And even then, a single node can have sub-pages - for instance, > a page showing a user profile can have a subpage user/graham/blog. > > It's better to see it this way: Every page is an individual piece of > content for itself, and still every page can have subpages. > > A directory, on the other hand, can have subpages, but is not that > interesting for itself. Which we don't want to happen - we want all > our pages to be interesting! > Think back to the days when all web pages were a collection of static html files. Every directory within the server root had an index page (usually index.html). That page could be found at any of the three urls: `/path/to/dir`, `/path/to/dir/`, or `/path/to/dir/index.html`. Obviously, not optimal. However, the recommendation was that the site author always link to such pages consistently so that only one of those urls would ever be used publicly. I think that's the "mental model" Graham is talking about. As crazy as it sound, I recall seeing someone who didn't like file extensions set up their site so that every single page was an index page -- that is every single page was in it's own directory, which may or may not have children. To easily tell if a page had children or not, a slash was always used by the author for pages that did and not for pages that did not. Granted, the author and a few other dev types who he told about it are probably the only people who ever noticed, but it made him feel better. And that's really what this whole discussion is all about - making the developer who chooses the url scheme feel good about it. The fact is, whether the url I'm told over the phone should have a slash at the end or not doesn't matter - it will lead me to the page I want whether I type that ending slash or not (at least through a redirect). Should Django support either choice by the site dev? Perhaps. Does it really matter though? Not really. Which is probably why the core devs have been completely silent on this issue. If it hasn't happened already, file a bug as a "nice-to-have" feature request, come up with the least invasive patch and wait for Django to get out of feature freeze status (it is currently for the upcoming 1.1 release - bug fixes only right now) and bring it up during the next proposal phase if it matters that much to you. I don't mean to be dismissive of something some of you obvious care a lot about, but this discussion has gone on endlessly and hasn't really gone anywhere. And for the record, no, I'm not anyone important and don't have any inside info on the core devs opinion, but I've seen their silence before, and given Django current state (feature freeze), well... there minds are focused elsewhere. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
On 17 Jun., 03:14, Graham Dumpleton wrote: > On Jun 17, 10:04 am, donquixote wrote: > > > I would still be interested to read some arguments in favour of the > > trailing slash. From a user perspective, it seems that without is > > better. > > The big issue with trailing slash, is that you should use a trailing > slash on a URL which represents an internal node in the URL tree which > can have sub nodes and which is intended to represent some > conglomerated view or directory listing onto those sub nodes. One can > probably leave it off where URL represents a leaf node of the tree, > just not the internal nodes. I don't think this fits the mental models people usually have of websites. "This is a listing with child nodes" vs "This is a single node." And even then, a single node can have sub-pages - for instance, a page showing a user profile can have a subpage user/graham/blog. It's better to see it this way: Every page is an individual piece of content for itself, and still every page can have subpages. A directory, on the other hand, can have subpages, but is not that interesting for itself. Which we don't want to happen - we want all our pages to be interesting! > > The reason for this is that by not having a trailing slash on URLs for > internal nodes, then if the response uses relative URLs to refer to > sub nodes, it will tend to break where trailing slash wasn't used. > This is because for trailing slash, you only need to have the sub node > name in relative URL because the browser will correctly then join them > together no problems. If the trailing slash is not present, then > relative URLs referring to sub nodes, would also need to include the > name of the directory node as the browser would otherwise drop the > internal node name of URL without the trailing slash before joining > them together. Firstly, the issue can be fixed using a tag. on http://.../user/donquixote/blog, the html [..] [..] Some Blog Post Title would send me to http://.../user/donquixote/blog/2009-06-17-some-blog-post-title Sure, it's a little bit of extra effort - especially, the script generating the page needs to know at least the last url fragment. But, it is certainly doable. Secondly, your explanation is entirely a technical one. It can make a developer's life easier to have this appended slash, but it says nothing about the user perspective. >From a developer's point of view, we could as well use ids in the url, instead of usernames.. > > So, although leaving off trailing slashes may make it look nicer, you > potentially break things because of how browsers work, or at least > make generation of relative URLs in responses a PITA. > > > But of course, I don't want to take away anyone's APPEND_SLASH > > setting. For an existing system, I think it's the best to keep the > > slashes. > > > > > > Please also note how the original proposal is made up of two ideas: > > 1. clean up the url typed by the user (by whatever standards you > > want), and redirect to the cleaned-up version. This will make the > > system tolerant to user input, but prevents undesired alias names from > > going into bookmarks or search engines. > > Which for repeating slashes cannot be done if hosting through Apache > as the repeating slashes are collapsed and not present in SCRIPT_NAME > or PATH_INFO. You therefore don't really know that repeating slashes > existed in order to trigger a redirect. If this is the case, then the multi-slash mechanics would not be useful for Apache setups. But, it's a side issue anyway. > > That there were repeating slashes is still recorded in REQUEST_URI, > but you shouldn't use that directly as there isn't necessarily a > direct relationship between that and SCRIPT_NAME and PATH_INFO because > of rewriting that may occur in Apache. > > The only sort of redirect that generally would be done, is to force a > URL without a trailing slash and which refers to an internal node in > URL tree, to have a trailing slash appended so that those relative > URLs work. Doing this means that user can use URL without trailing > slash if they want, but application will ensure that browser adds one > such that things work properly. > > So, what is the real issue here? The issue is: The redirect policy defines how urls will look when they go copypasted into bookmarks, emails, forum threads, google search results, how people will tell them on the phone, etc. You can even see them as a part of brand identity. From this point of view, a trailing slash is just unnecessary ballast, without a semantic value. > That you don't like that the browser shows a trailing slash when on a > URL representing an internal node, I just think it doesn't help much to make internal nodes and leaf nodes look different in the url. After all, every leaf node can easily become an internal node, only by adding a subpage, but trying to reflect that by adding a slash would confuse more than it helps. > or that the user has to h
Re: append_slash alternative: remove_slash
I think the multiple slashes are a quite theoretical problem. - The server might remove them anyway - People will know that this is a typo. The only reason why I talked about multiple slashes was for the sake of completeness: If we discuss a remove_slash solution, then why not clean up the complete house. But maybe it's just not necessary. On 17 Jun., 15:18, Justin Myers wrote: > On Jun 16, 6:07 pm, Graham Dumpleton > wrote: > > > On Jun 16, 10:55 pm, Justin Myers wrote: > > > Which hopefully will bring us back on topic: Regardless of our > > > individual feelings on the trailing-slash holy war here, Patrick said > > > it best--let's have a way to get rid of the URLs we agree are bad > > > (multiple consecutive slashes) > > > What hosting mechanism are you using? From memory Apache with > > mod_python, mod_wsgi and possibly even mod_fastcgi or mod_fcgid should > > see the repeating slashes be collapsed by Apache. I can't check this > > at the moment, otherwise I would. :-) > > I've never come across that particular problem myself, so I can't say > what would or wouldn't cause it--but the original post mentioned it as > a possibility (one I don't know much about) and other people seemed to > agree it's not a good thing, so I brought it up here to summarize what > we could agree on so far. Apologies if it caused any confusion. > > -Justin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
On Jun 16, 6:07 pm, Graham Dumpleton wrote: > On Jun 16, 10:55 pm, Justin Myers wrote: > > Which hopefully will bring us back on topic: Regardless of our > > individual feelings on the trailing-slash holy war here, Patrick said > > it best--let's have a way to get rid of the URLs we agree are bad > > (multiple consecutive slashes) > > What hosting mechanism are you using? From memory Apache with > mod_python, mod_wsgi and possibly even mod_fastcgi or mod_fcgid should > see the repeating slashes be collapsed by Apache. I can't check this > at the moment, otherwise I would. :-) I've never come across that particular problem myself, so I can't say what would or wouldn't cause it--but the original post mentioned it as a possibility (one I don't know much about) and other people seemed to agree it's not a good thing, so I brought it up here to summarize what we could agree on so far. Apologies if it caused any confusion. -Justin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
Thanks for pointing me to the bikeshed. It is an excellent topic that I wasn't aware of. Anyway, I'm still not understanding how this topic relates to my reply. On Jun 17, 2009, at 6:25 AM, Russell Keith-Magee wrote: > > On Wed, Jun 17, 2009 at 5:02 AM, M. N. Islam > Shihan wrote: >> >> On Jun 17, 2009, at 2:27 AM, Hanne Moa wrote: >>> >>> And I want the bikeshed to be painted blue with yellow stars on. >> >> ??? > > For an explanation, see http://www.bikeshed.com/ > > For extra amusement, reload the page a few times :-) > > Yours, > Russ Magee %-) > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
You are right! I always had assumed the browser would understand these relative urls no matter if slash or not. I made a test, and it turns out I was wrong. A lot of websites out there either don't use relative urls, or they use a tag etc. Others (such as wikipedia) make their URLs relative to web root, with a preceding slash. For a user I would say it looks nicer without the slash, but it's only a subtle difference. So.. I can see how someone would prefer urls with slash, or even a mixed system where only "leave" nodes have no slash. I am curious how many developers actually use relative urls without a base tag, where they can take advantage of the slash. On Jun 17, 3:14 am, Graham Dumpleton wrote: > On Jun 17, 10:04 am, donquixote wrote: > > > I would still be interested to read some arguments in favour of the > > trailing slash. From a user perspective, it seems that without is > > better. > > The big issue with trailing slash, is that you should use a trailing > slash on a URL which represents an internal node in the URL tree which > can have sub nodes and which is intended to represent some > conglomerated view or directory listing onto those sub nodes. One can > probably leave it off where URL represents a leaf node of the tree, > just not the internal nodes. > > The reason for this is that by not having a trailing slash on URLs for > internal nodes, then if the response uses relative URLs to refer to > sub nodes, it will tend to break where trailing slash wasn't used. > This is because for trailing slash, you only need to have the sub node > name in relative URL because the browser will correctly then join them > together no problems. If the trailing slash is not present, then > relative URLs referring to sub nodes, would also need to include the > name of the directory node as the browser would otherwise drop the > internal node name of URL without the trailing slash before joining > them together. > > So, although leaving off trailing slashes may make it look nicer, you > potentially break things because of how browsers work, or at least > make generation of relative URLs in responses a PITA. > > > But of course, I don't want to take away anyone's APPEND_SLASH > > setting. For an existing system, I think it's the best to keep the > > slashes. > > > > > > Please also note how the original proposal is made up of two ideas: > > 1. clean up the url typed by the user (by whatever standards you > > want), and redirect to the cleaned-up version. This will make the > > system tolerant to user input, but prevents undesired alias names from > > going into bookmarks or search engines. > > Which for repeating slashes cannot be done if hosting through Apache > as the repeating slashes are collapsed and not present in SCRIPT_NAME > or PATH_INFO. You therefore don't really know that repeating slashes > existed in order to trigger a redirect. > > That there were repeating slashes is still recorded in REQUEST_URI, > but you shouldn't use that directly as there isn't necessarily a > direct relationship between that and SCRIPT_NAME and PATH_INFO because > of rewriting that may occur in Apache. > > The only sort of redirect that generally would be done, is to force a > URL without a trailing slash and which refers to an internal node in > URL tree, to have a trailing slash appended so that those relative > URLs work. Doing this means that user can use URL without trailing > slash if they want, but application will ensure that browser adds one > such that things work properly. > > So, what is the real issue here? That you don't like that the browser > shows a trailing slash when on a URL representing an internal node, or > that the user has to have the trailing slash when they enter the URL > because the application isn't properly redirecting the browser to use > a trailing slash when it should be. > > Graham > > > > > 2. The dispatcher tries the regex route definitions with two different > > versions of the request url (with priority rules of your choice). This > > allows the programmer to write sloppy regex, which can make the job a > > lot easier. It also allows to include url definitions from packages > > which assume a different slash policy. > > > As has been pointed out by others in this thread, the policy of slash > > or not slash should be consistent within one project, so most projects > > will not need to make this decision again for every single route > > definition. > > > On Jun 17, 1:07 am, Graham Dumpleton > > wrote: > > > > On Jun 16, 10:55 pm, Justin Myers wrote: > > > > > On Jun 16, 3:49 am, Ivan Sagalaev wrote: > > > > > > Indeed I don't really want to discuss the proposal itself (I don't > > > > > really care of the outcome since you don't propose to remove > > > > > APPEND_SLASH altogether). I was just trying to show that bashing some > > > > > people's preference doesn't help in making a point. Feel free to > > > > > ignore > > > > > the advice. > > > > > Which hopefully will
Re: append_slash alternative: remove_slash
On Jun 17, 10:04 am, donquixote wrote: > I would still be interested to read some arguments in favour of the > trailing slash. From a user perspective, it seems that without is > better. The big issue with trailing slash, is that you should use a trailing slash on a URL which represents an internal node in the URL tree which can have sub nodes and which is intended to represent some conglomerated view or directory listing onto those sub nodes. One can probably leave it off where URL represents a leaf node of the tree, just not the internal nodes. The reason for this is that by not having a trailing slash on URLs for internal nodes, then if the response uses relative URLs to refer to sub nodes, it will tend to break where trailing slash wasn't used. This is because for trailing slash, you only need to have the sub node name in relative URL because the browser will correctly then join them together no problems. If the trailing slash is not present, then relative URLs referring to sub nodes, would also need to include the name of the directory node as the browser would otherwise drop the internal node name of URL without the trailing slash before joining them together. So, although leaving off trailing slashes may make it look nicer, you potentially break things because of how browsers work, or at least make generation of relative URLs in responses a PITA. > But of course, I don't want to take away anyone's APPEND_SLASH > setting. For an existing system, I think it's the best to keep the > slashes. > > > > Please also note how the original proposal is made up of two ideas: > 1. clean up the url typed by the user (by whatever standards you > want), and redirect to the cleaned-up version. This will make the > system tolerant to user input, but prevents undesired alias names from > going into bookmarks or search engines. Which for repeating slashes cannot be done if hosting through Apache as the repeating slashes are collapsed and not present in SCRIPT_NAME or PATH_INFO. You therefore don't really know that repeating slashes existed in order to trigger a redirect. That there were repeating slashes is still recorded in REQUEST_URI, but you shouldn't use that directly as there isn't necessarily a direct relationship between that and SCRIPT_NAME and PATH_INFO because of rewriting that may occur in Apache. The only sort of redirect that generally would be done, is to force a URL without a trailing slash and which refers to an internal node in URL tree, to have a trailing slash appended so that those relative URLs work. Doing this means that user can use URL without trailing slash if they want, but application will ensure that browser adds one such that things work properly. So, what is the real issue here? That you don't like that the browser shows a trailing slash when on a URL representing an internal node, or that the user has to have the trailing slash when they enter the URL because the application isn't properly redirecting the browser to use a trailing slash when it should be. Graham > 2. The dispatcher tries the regex route definitions with two different > versions of the request url (with priority rules of your choice). This > allows the programmer to write sloppy regex, which can make the job a > lot easier. It also allows to include url definitions from packages > which assume a different slash policy. > > As has been pointed out by others in this thread, the policy of slash > or not slash should be consistent within one project, so most projects > will not need to make this decision again for every single route > definition. > > On Jun 17, 1:07 am, Graham Dumpleton > wrote: > > > > > On Jun 16, 10:55 pm, Justin Myers wrote: > > > > On Jun 16, 3:49 am, Ivan Sagalaev wrote: > > > > > Indeed I don't really want to discuss the proposal itself (I don't > > > > really care of the outcome since you don't propose to remove > > > > APPEND_SLASH altogether). I was just trying to show that bashing some > > > > people's preference doesn't help in making a point. Feel free to ignore > > > > the advice. > > > > Which hopefully will bring us back on topic: Regardless of our > > > individual feelings on the trailing-slash holy war here, Patrick said > > > it best--let's have a way to get rid of the URLs we agree are bad > > > (multiple consecutive slashes) > > > What hosting mechanism are you using? From memory Apache with > > mod_python, mod_wsgi and possibly even mod_fastcgi or mod_fcgid should > > see the repeating slashes be collapsed by Apache. I can't check this > > at the moment, otherwise I would. :-) > > > Graham > > > > and a way to choose whether we want to > > > append or remove the trailing slash. > > > > The whole point is consistency in order to help keep our search > > > results and rankings in line--which I think we can all agree is a Good > > > Thing. Anyone interested in working on it? --~--~-~--~~~---~--~~ You received this message because you
Re: append_slash alternative: remove_slash
On Wed, Jun 17, 2009 at 5:02 AM, M. N. Islam Shihan wrote: > > On Jun 17, 2009, at 2:27 AM, Hanne Moa wrote: >> >> And I want the bikeshed to be painted blue with yellow stars on. > > ??? For an explanation, see http://www.bikeshed.com/ For extra amusement, reload the page a few times :-) Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
I would still be interested to read some arguments in favour of the trailing slash. From a user perspective, it seems that without is better. But of course, I don't want to take away anyone's APPEND_SLASH setting. For an existing system, I think it's the best to keep the slashes. Please also note how the original proposal is made up of two ideas: 1. clean up the url typed by the user (by whatever standards you want), and redirect to the cleaned-up version. This will make the system tolerant to user input, but prevents undesired alias names from going into bookmarks or search engines. 2. The dispatcher tries the regex route definitions with two different versions of the request url (with priority rules of your choice). This allows the programmer to write sloppy regex, which can make the job a lot easier. It also allows to include url definitions from packages which assume a different slash policy. As has been pointed out by others in this thread, the policy of slash or not slash should be consistent within one project, so most projects will not need to make this decision again for every single route definition. On Jun 17, 1:07 am, Graham Dumpleton wrote: > On Jun 16, 10:55 pm, Justin Myers wrote: > > > On Jun 16, 3:49 am, Ivan Sagalaev wrote: > > > > Indeed I don't really want to discuss the proposal itself (I don't > > > really care of the outcome since you don't propose to remove > > > APPEND_SLASH altogether). I was just trying to show that bashing some > > > people's preference doesn't help in making a point. Feel free to ignore > > > the advice. > > > Which hopefully will bring us back on topic: Regardless of our > > individual feelings on the trailing-slash holy war here, Patrick said > > it best--let's have a way to get rid of the URLs we agree are bad > > (multiple consecutive slashes) > > What hosting mechanism are you using? From memory Apache with > mod_python, mod_wsgi and possibly even mod_fastcgi or mod_fcgid should > see the repeating slashes be collapsed by Apache. I can't check this > at the moment, otherwise I would. :-) > > Graham > > > > > and a way to choose whether we want to > > append or remove the trailing slash. > > > The whole point is consistency in order to help keep our search > > results and rankings in line--which I think we can all agree is a Good > > Thing. Anyone interested in working on it? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
On Jun 16, 10:55 pm, Justin Myers wrote: > On Jun 16, 3:49 am, Ivan Sagalaev wrote: > > > Indeed I don't really want to discuss the proposal itself (I don't > > really care of the outcome since you don't propose to remove > > APPEND_SLASH altogether). I was just trying to show that bashing some > > people's preference doesn't help in making a point. Feel free to ignore > > the advice. > > Which hopefully will bring us back on topic: Regardless of our > individual feelings on the trailing-slash holy war here, Patrick said > it best--let's have a way to get rid of the URLs we agree are bad > (multiple consecutive slashes) What hosting mechanism are you using? From memory Apache with mod_python, mod_wsgi and possibly even mod_fastcgi or mod_fcgid should see the repeating slashes be collapsed by Apache. I can't check this at the moment, otherwise I would. :-) Graham > and a way to choose whether we want to > append or remove the trailing slash. > > The whole point is consistency in order to help keep our search > results and rankings in line--which I think we can all agree is a Good > Thing. Anyone interested in working on it? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
??? On Jun 17, 2009, at 2:27 AM, Hanne Moa wrote: > > On Tue, Jun 16, 2009 at 22:08, M. N. Islam > Shihan wrote: >> I think another toggle flag ENABLE_REMOVE_SLASH_MODE (or any other >> appropriate name) can be added to the settings.py and setting that >> tlag to true will alter the existing APPEND_SLASH flag to be treated >> as prposed REMOVE_SLASH setting and act accordingly. In this way the >> existing APPEND_SLASH will act like a tristate variable to dictate >> url >> resolver to append slash (APPEND_SLASH true, ENABLE_REMOVE_SLASH_MODE >> false), do nothing (APPEND_SLASH false, ENABLE_REMOVE_SLASH_MODE >> false >> and APPEND_SLASH false, ENABLE_REMOVE_SLASH_MODE true) and remove >> slash (APPEND_SLASH true, ENABLE_REMOVE_SLASH_MODE true). In all >> cases >> the extra slashes should be removed anyway. > > And I want the bikeshed to be painted blue with yellow stars on. > > > HM > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
On Tue, Jun 16, 2009 at 22:08, M. N. Islam Shihan wrote: > I think another toggle flag ENABLE_REMOVE_SLASH_MODE (or any other > appropriate name) can be added to the settings.py and setting that > tlag to true will alter the existing APPEND_SLASH flag to be treated > as prposed REMOVE_SLASH setting and act accordingly. In this way the > existing APPEND_SLASH will act like a tristate variable to dictate url > resolver to append slash (APPEND_SLASH true, ENABLE_REMOVE_SLASH_MODE > false), do nothing (APPEND_SLASH false, ENABLE_REMOVE_SLASH_MODE false > and APPEND_SLASH false, ENABLE_REMOVE_SLASH_MODE true) and remove > slash (APPEND_SLASH true, ENABLE_REMOVE_SLASH_MODE true). In all cases > the extra slashes should be removed anyway. And I want the bikeshed to be painted blue with yellow stars on. HM --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
I think another toggle flag ENABLE_REMOVE_SLASH_MODE (or any other appropriate name) can be added to the settings.py and setting that tlag to true will alter the existing APPEND_SLASH flag to be treated as prposed REMOVE_SLASH setting and act accordingly. In this way the existing APPEND_SLASH will act like a tristate variable to dictate url resolver to append slash (APPEND_SLASH true, ENABLE_REMOVE_SLASH_MODE false), do nothing (APPEND_SLASH false, ENABLE_REMOVE_SLASH_MODE false and APPEND_SLASH false, ENABLE_REMOVE_SLASH_MODE true) and remove slash (APPEND_SLASH true, ENABLE_REMOVE_SLASH_MODE true). In all cases the extra slashes should be removed anyway. Cheers Shihan On Jun 16, 2009, at 6:55 PM, Justin end Myers wrote > > On Jun 16, 3:49 am, Ivan Sagalaev wrote: >> Indeed I don't really want to discuss the proposal itself (I don't >> really care of the outcome since you don't propose to remove >> APPEND_SLASH altogether). I was just trying to show that bashing some >> people's preference doesn't help in making a point. Feel free to >> ignore >> the advice. > > Which hopefully will bring us back on topic: Regardless of our > individual feelings on the trailing-slash holy war here, Patrick said > it best--let's have a way to get rid of the URLs we agree are bad > (multiple consecutive slashes) and a way to choose whether we want to > append or remove the trailing slash. > > The whole point is consistency in order to help keep our search > results and rankings in line--which I think we can all agree is a Good > Thing. Anyone interested in working on it? > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
On Sunday 14 June 2009 06:12:32 donquixote wrote: > Nice (i): > http://mysite.org/members/emil > http://mysite.org/members/emil/contact > > Not nice (ii): > http://mysite.org/members/emil/ > http://mysite.org/members/emil/contact/ You have some problems: 1) All contrib apps, and many others, put a slash at end of the URL conf regexes. This means that without APPEND_SLASH = True, you will get 404s for e.g. /admin/foo which is not very friendly behaviour. 2) Having more than one convention is not going to be popular - especially as django apps are often designed to be pluggable. Inconsistency here would be a pain in neck 3) Changing these existing apps to make the trailing slash optional would be a *very* big task, especially when you use relative URLs like href="../../somewhere/else/". If the current URL doesn't have a trailing slash, then those relative URLs will be broken. In theory, this should be fixed by use URL reversing correctly, but there isn't even a fully capable solution in trunk yet (I believe the current status is some design decisions need to be made with regards to the case where you have multiple instances of the same app, I might be wrong). Anyway, there are *many* instances of relative URLs still in the Django code base. And I think it affects CSS too (which is not so easily addressed as template or Python code). Seeing as some people actually prefer the trailing slash, I think it is fair to say that you are fighting a losing battle. Luke -- "If we could just get everyone to close their eyes and visualise world peace for an hour, imagine how serene and quiet it would be until the looting started" -- Anon Luke Plant || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
I have never messed with this part of Django but I'm up for a try; by the end of this month I'll have some time off to work on it if no one else is able to. Feel free to file a ticket. On Jun 16, 3:55 pm, Justin Myers wrote: > On Jun 16, 3:49 am, Ivan Sagalaev wrote: > > > Indeed I don't really want to discuss the proposal itself (I don't > > really care of the outcome since you don't propose to remove > > APPEND_SLASH altogether). I was just trying to show that bashing some > > people's preference doesn't help in making a point. Feel free to ignore > > the advice. > > Which hopefully will bring us back on topic: Regardless of our > individual feelings on the trailing-slash holy war here, Patrick said > it best--let's have a way to get rid of the URLs we agree are bad > (multiple consecutive slashes) and a way to choose whether we want to > append or remove the trailing slash. > > The whole point is consistency in order to help keep our search > results and rankings in line--which I think we can all agree is a Good > Thing. Anyone interested in working on it? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
On Jun 16, 3:49 am, Ivan Sagalaev wrote: > Indeed I don't really want to discuss the proposal itself (I don't > really care of the outcome since you don't propose to remove > APPEND_SLASH altogether). I was just trying to show that bashing some > people's preference doesn't help in making a point. Feel free to ignore > the advice. Which hopefully will bring us back on topic: Regardless of our individual feelings on the trailing-slash holy war here, Patrick said it best--let's have a way to get rid of the URLs we agree are bad (multiple consecutive slashes) and a way to choose whether we want to append or remove the trailing slash. The whole point is consistency in order to help keep our search results and rankings in line--which I think we can all agree is a Good Thing. Anyone interested in working on it? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
Adys wrote: > And please don't speak "on behalf" of other Django developers. I don't. It's a simple matter of fact that APPEND_SLASH defaults to True and CommonMiddleware is installed be default and djangoproject.com uses trailing slash and first four sites from http://djangosites.org/ also do this. And though I can't find it by now, I remember that back in 2005 somewhere in Django FAQ there was a personal reference from core developers that they prefer URLs with slashes. > If you indeed cannot bear yourself to conveniently > discuss something, your post was not necessary in any way. Indeed I don't really want to discuss the proposal itself (I don't really care of the outcome since you don't propose to remove APPEND_SLASH altogether). I was just trying to show that bashing some people's preference doesn't help in making a point. Feel free to ignore the advice. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
On Jun 16, 11:27 am, Ivan Sagalaev wrote: > Sorry for interrupting your lively conversation gentlemen... If you > allow me to give an advice then your proposal will look better without > constantly referring to one trailing slash with disparaging adjectives > (such as "unclean"). Most of Django world actually prefers this variant. > Which is not a way of saying that the proposal is useless, I just can't > bear myself to discuss things from my supposedly "unclean" position. Wow, hold your fire there. I said "unclean" because the proposed setting would "clean up" the url. And please don't speak "on behalf" of other Django developers. I didn't aim anything at anyone, the entire point is to have an additional setting. If you indeed cannot bear yourself to conveniently discuss something, your post was not necessary in any way. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
Adys wrote: > Clean: > http://example.com/foo/bar > > Unclean > http://example.com/foo/bar/ > http://example.com/foo///bar > http://example.com///foo//bar/// Sorry for interrupting your lively conversation gentlemen... If you allow me to give an advice then your proposal will look better without constantly referring to one trailing slash with disparaging adjectives (such as "unclean"). Most of Django world actually prefers this variant. Which is not a way of saying that the proposal is useless, I just can't bear myself to discuss things from my supposedly "unclean" position. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
On 15-Jun-09, at 6:50 PM, donquixote wrote: > > @Adys: > As I understand, Justin's "remove all slashes" was just a hypothetical > example. > > @Justin: > I agree that it's not about avoiding an illusion. It's just ugly and > unhandy, that's it. And yes, most non-django systems out there that I > can think of do either have crappy old school urls, or nice ones > without a trailing slash. Actually, it's a much starker division: there is a universe-full of systems with crappy URIs and then there is an infinitesimal number of frameworks and CMS that care about URIs (including Django and the ones which hate trailing slashes). Of the ones that care, some choose to emulate a "non-crufty" file --- a file name without an extension-- and others choose to emulate the behaviour of a web directory with a default file in it (hence the trailing slash) which is the way Django does it. Neither is wrong, one just happens to be currently a slightly more popular minority opinion. The really important thing is maintaining URI consistency which is (I believe) the real reason the core developers added the APPEND_SLASH. I like the trailing slash and can argue in favour just as passionately as you guys can against it ... however I'm not against your proposal in principle. If this doesn't get labelled WONTFIX (and it might), my vote would be to split the proposal into two halves: 1. automatically remove truly excessive slashes TRULY CRUFTY URIs --- > http://example.com/foo///bar > http://example.com///foo//bar/// 2. Perhaps have a TRAILING_SLASH setting which would allow developers to choose their preferred canonical URI scheme (with trailing slash or without) by setting it to True or False. A PERSONAL CHOICE AS TO WHICH IS THE CRUFTY URI and WHICH ONE ISN'T --- > http://example.com/foo/bar > http://example.com/foo/bar/ I'm happy, you're pretty happy (except when you surf one of my websites) ... the true goal --that of maintaining URI consistency on a webserver-- is preserved. Patrick > > - > > (preaching mode on) > Why care about URLs anyway? They should look nice in the address bar, > yes.. but to see their real relevance, you should think about what > people might do with them! > - type it: "example.com/foo/bar/" > - dicate it on the phone: "example dot com slash foo slash bar slash" > - store it in a bookmark > - send it in an email, or put it in a forum post > - look at a list full of urls (such as web search results) > - make sense of the hierarchic structure of a website: Slashes are > useful for that, but not the one in the end! > > So really, we should be happy about any meaningless symbol we can get > rid of! > But I think we all agree on that so far. Let's see what comes out! > > Btw, I'm quite new to django, I was a bit surprised to see this > append_slash thing. Otherwise, it looks nice. > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
@Adys: As I understand, Justin's "remove all slashes" was just a hypothetical example. @Justin: I agree that it's not about avoiding an illusion. It's just ugly and unhandy, that's it. And yes, most non-django systems out there that I can think of do either have crappy old school urls, or nice ones without a trailing slash. - (preaching mode on) Why care about URLs anyway? They should look nice in the address bar, yes.. but to see their real relevance, you should think about what people might do with them! - type it: "example.com/foo/bar/" - dicate it on the phone: "example dot com slash foo slash bar slash" - store it in a bookmark - send it in an email, or put it in a forum post - look at a list full of urls (such as web search results) - make sense of the hierarchic structure of a website: Slashes are useful for that, but not the one in the end! So really, we should be happy about any meaningless symbol we can get rid of! But I think we all agree on that so far. Let's see what comes out! Btw, I'm quite new to django, I was a bit surprised to see this append_slash thing. Otherwise, it looks nice. donquixote On Jun 15, 11:19 pm, Adys wrote: > Are you sure you understood the original proposal? > No one here wants to remove all slashes! Just "cleanup" the url: > Clean:http://example.com/foo/bar > > Uncleanhttp://example.com/foo/bar/http://example.com/foo///barhttp://example.com///foo//bar/// > > The last two would be a more aggressive setting. > > On Jun 15, 6:24 pm, Justin Myers wrote: > > > > > I can appreciate the need for this setting (among other things, it > > might make migrating URLs from systems where this is more standard > > (e.g., Drupal) simpler), but I wouldn't go so far as to talk about an > > "illusion". > > > Unless we're proposing to remove all slashes from all URLs--which is > > certainly possible with our URL system--there's always going to be > > some hint of that, but I think the slashes represent a hierarchy more > > than they do a directory structure. Sure, directories were a big > > influence on why the slashes ended up there in the first place, but I > > don't think anyone is sufficiently taken by this "illusion" that they > > think there's actually a file called "2b6a459329fe498a" in a folder > > called "thread" when they read this discussion... > > > -Justin > > > On Jun 14, 12:53 am, "M. N. Islam Shihan" wrote: > > > > +1 > > > > I also like the remove_slash version of urls over the append_slash > > > version as the trailing slash creates a directory structure illusion > > > which is not true. > > > > Cheers > > > Shihan > > > > On Jun 14, 2009, at 11:12 AM, donquixote > > > wrote: > > > > > Ok, I know similar questions have been asked about the trailing slash > > > > before. See > > > >http://groups.google.com/group/django-developers/browse_thread/thread... > > > > > My proposal is a little different: > > > > - I agree there should be only one url for each page. Any alias urls > > > > should be redirected. > > > > - I think that trailing slashes look ugly, and should be avoided for > > > > good style. > > > > > Nice (i): > > > >http://mysite.org/members/emil > > > >http://mysite.org/members/emil/contact > > > > > Not nice (ii): > > > >http://mysite.org/members/emil/ > > > >http://mysite.org/members/emil/contact/ > > > > > Even worse (iii): > > > >http://mysite.org/members/emil > > > > etc > > > > > Or worst (iv): > > > >http://mysite.orgmembersemil > > > > > So, ideally I want the (ii) and (iii) and (iv) type of urls (with more > > > > slashes than needed) redirected to the first type of urls (with no > > > > trailing slash, and no duplicate slashes). For the duplicates I don't > > > > care that much, most important is the case (ii) with one trailing > > > > slash. > > > > > And this is how I imagine this to work: > > > > - In addition to the existing option of append_slash, we get one more > > > > option, which is remove_slash. > > > > - With the setting enabled, for any given url there will be two > > > > versions computed: One reduced version without duplicates and without > > > > trailing slash, and one version without duplicates but with one > > > > trailing slash appended. > > > > - The dispatcher will give both versions a try. > > > > - If the original url had a trailing or duplicate slash, and no other > > > > redirect directive has been triggered, the request will be redirected > > > > to the reduced version. > > > > - If the original url was "clean", django can now execute the action > > > > determined by the dispatcher. > > > > > I think this will be more useful than the append_slash mechanic. > > > > > Thanks! > > > > donquixote --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to djan
Re: append_slash alternative: remove_slash
Are you sure you understood the original proposal? No one here wants to remove all slashes! Just "cleanup" the url: Clean: http://example.com/foo/bar Unclean http://example.com/foo/bar/ http://example.com/foo///bar http://example.com///foo//bar/// The last two would be a more aggressive setting. On Jun 15, 6:24 pm, Justin Myers wrote: > I can appreciate the need for this setting (among other things, it > might make migrating URLs from systems where this is more standard > (e.g., Drupal) simpler), but I wouldn't go so far as to talk about an > "illusion". > > Unless we're proposing to remove all slashes from all URLs--which is > certainly possible with our URL system--there's always going to be > some hint of that, but I think the slashes represent a hierarchy more > than they do a directory structure. Sure, directories were a big > influence on why the slashes ended up there in the first place, but I > don't think anyone is sufficiently taken by this "illusion" that they > think there's actually a file called "2b6a459329fe498a" in a folder > called "thread" when they read this discussion... > > -Justin > > On Jun 14, 12:53 am, "M. N. Islam Shihan" wrote: > > > +1 > > > I also like the remove_slash version of urls over the append_slash > > version as the trailing slash creates a directory structure illusion > > which is not true. > > > Cheers > > Shihan > > > On Jun 14, 2009, at 11:12 AM, donquixote > > wrote: > > > > Ok, I know similar questions have been asked about the trailing slash > > > before. See > > >http://groups.google.com/group/django-developers/browse_thread/thread... > > > > My proposal is a little different: > > > - I agree there should be only one url for each page. Any alias urls > > > should be redirected. > > > - I think that trailing slashes look ugly, and should be avoided for > > > good style. > > > > Nice (i): > > >http://mysite.org/members/emil > > >http://mysite.org/members/emil/contact > > > > Not nice (ii): > > >http://mysite.org/members/emil/ > > >http://mysite.org/members/emil/contact/ > > > > Even worse (iii): > > >http://mysite.org/members/emil > > > etc > > > > Or worst (iv): > > >http://mysite.orgmembersemil > > > > So, ideally I want the (ii) and (iii) and (iv) type of urls (with more > > > slashes than needed) redirected to the first type of urls (with no > > > trailing slash, and no duplicate slashes). For the duplicates I don't > > > care that much, most important is the case (ii) with one trailing > > > slash. > > > > And this is how I imagine this to work: > > > - In addition to the existing option of append_slash, we get one more > > > option, which is remove_slash. > > > - With the setting enabled, for any given url there will be two > > > versions computed: One reduced version without duplicates and without > > > trailing slash, and one version without duplicates but with one > > > trailing slash appended. > > > - The dispatcher will give both versions a try. > > > - If the original url had a trailing or duplicate slash, and no other > > > redirect directive has been triggered, the request will be redirected > > > to the reduced version. > > > - If the original url was "clean", django can now execute the action > > > determined by the dispatcher. > > > > I think this will be more useful than the append_slash mechanic. > > > > Thanks! > > > donquixote --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
I can appreciate the need for this setting (among other things, it might make migrating URLs from systems where this is more standard (e.g., Drupal) simpler), but I wouldn't go so far as to talk about an "illusion". Unless we're proposing to remove all slashes from all URLs--which is certainly possible with our URL system--there's always going to be some hint of that, but I think the slashes represent a hierarchy more than they do a directory structure. Sure, directories were a big influence on why the slashes ended up there in the first place, but I don't think anyone is sufficiently taken by this "illusion" that they think there's actually a file called "2b6a459329fe498a" in a folder called "thread" when they read this discussion... -Justin On Jun 14, 12:53 am, "M. N. Islam Shihan" wrote: > +1 > > I also like the remove_slash version of urls over the append_slash > version as the trailing slash creates a directory structure illusion > which is not true. > > Cheers > Shihan > > On Jun 14, 2009, at 11:12 AM, donquixote > wrote: > > > > > Ok, I know similar questions have been asked about the trailing slash > > before. See > >http://groups.google.com/group/django-developers/browse_thread/thread... > > > My proposal is a little different: > > - I agree there should be only one url for each page. Any alias urls > > should be redirected. > > - I think that trailing slashes look ugly, and should be avoided for > > good style. > > > Nice (i): > >http://mysite.org/members/emil > >http://mysite.org/members/emil/contact > > > Not nice (ii): > >http://mysite.org/members/emil/ > >http://mysite.org/members/emil/contact/ > > > Even worse (iii): > >http://mysite.org/members/emil > > etc > > > Or worst (iv): > >http://mysite.orgmembersemil > > > So, ideally I want the (ii) and (iii) and (iv) type of urls (with more > > slashes than needed) redirected to the first type of urls (with no > > trailing slash, and no duplicate slashes). For the duplicates I don't > > care that much, most important is the case (ii) with one trailing > > slash. > > > And this is how I imagine this to work: > > - In addition to the existing option of append_slash, we get one more > > option, which is remove_slash. > > - With the setting enabled, for any given url there will be two > > versions computed: One reduced version without duplicates and without > > trailing slash, and one version without duplicates but with one > > trailing slash appended. > > - The dispatcher will give both versions a try. > > - If the original url had a trailing or duplicate slash, and no other > > redirect directive has been triggered, the request will be redirected > > to the reduced version. > > - If the original url was "clean", django can now execute the action > > determined by the dispatcher. > > > I think this will be more useful than the append_slash mechanic. > > > Thanks! > > donquixote --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
+1 I also like the remove_slash version of urls over the append_slash version as the trailing slash creates a directory structure illusion which is not true. Cheers Shihan On Jun 14, 2009, at 11:12 AM, donquixote wrote: > > Ok, I know similar questions have been asked about the trailing slash > before. See > http://groups.google.com/group/django-developers/browse_thread/thread/78f370da90a5a268/6e95edb134564009?lnk=gst&q=append_slash > > My proposal is a little different: > - I agree there should be only one url for each page. Any alias urls > should be redirected. > - I think that trailing slashes look ugly, and should be avoided for > good style. > > Nice (i): > http://mysite.org/members/emil > http://mysite.org/members/emil/contact > > Not nice (ii): > http://mysite.org/members/emil/ > http://mysite.org/members/emil/contact/ > > Even worse (iii): > http://mysite.org/members/emil > etc > > Or worst (iv): > http://mysite.orgmembersemil > > So, ideally I want the (ii) and (iii) and (iv) type of urls (with more > slashes than needed) redirected to the first type of urls (with no > trailing slash, and no duplicate slashes). For the duplicates I don't > care that much, most important is the case (ii) with one trailing > slash. > > And this is how I imagine this to work: > - In addition to the existing option of append_slash, we get one more > option, which is remove_slash. > - With the setting enabled, for any given url there will be two > versions computed: One reduced version without duplicates and without > trailing slash, and one version without duplicates but with one > trailing slash appended. > - The dispatcher will give both versions a try. > - If the original url had a trailing or duplicate slash, and no other > redirect directive has been triggered, the request will be redirected > to the reduced version. > - If the original url was "clean", django can now execute the action > determined by the dispatcher. > > I think this will be more useful than the append_slash mechanic. > > Thanks! > donquixote > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: append_slash alternative: remove_slash
I've been looking for this, as an user. I can only agree with the
proposal.
I think a single setting would be less confusing though:
TRAILING_SLASH = ("append", "remove", "remove_last", "full_clean") for
the different methods you described. Or maybe that's just overdoing
it... For backwards-compatibility's sake, the setting APPEND_SLASH =
True would overwrite TRAILING_SLASH, or something.
Jerome
On Jun 14, 8:12 am, donquixote wrote:
> Ok, I know similar questions have been asked about the trailing slash
> before.
> Seehttp://groups.google.com/group/django-developers/browse_thread/thread...
>
> My proposal is a little different:
> - I agree there should be only one url for each page. Any alias urls
> should be redirected.
> - I think that trailing slashes look ugly, and should be avoided for
> good style.
>
> Nice (i):http://mysite.org/members/emilhttp://mysite.org/members/emil/contact
>
> Not nice
> (ii):http://mysite.org/members/emil/http://mysite.org/members/emil/contact/
>
> Even worse (iii):http://mysite.org/members/emil
> etc
>
> Or worst (iv):http://mysite.orgmembersemil
>
> So, ideally I want the (ii) and (iii) and (iv) type of urls (with more
> slashes than needed) redirected to the first type of urls (with no
> trailing slash, and no duplicate slashes). For the duplicates I don't
> care that much, most important is the case (ii) with one trailing
> slash.
>
> And this is how I imagine this to work:
> - In addition to the existing option of append_slash, we get one more
> option, which is remove_slash.
> - With the setting enabled, for any given url there will be two
> versions computed: One reduced version without duplicates and without
> trailing slash, and one version without duplicates but with one
> trailing slash appended.
> - The dispatcher will give both versions a try.
> - If the original url had a trailing or duplicate slash, and no other
> redirect directive has been triggered, the request will be redirected
> to the reduced version.
> - If the original url was "clean", django can now execute the action
> determined by the dispatcher.
>
> I think this will be more useful than the append_slash mechanic.
>
> Thanks!
> donquixote
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
append_slash alternative: remove_slash
Ok, I know similar questions have been asked about the trailing slash before. See http://groups.google.com/group/django-developers/browse_thread/thread/78f370da90a5a268/6e95edb134564009?lnk=gst&q=append_slash My proposal is a little different: - I agree there should be only one url for each page. Any alias urls should be redirected. - I think that trailing slashes look ugly, and should be avoided for good style. Nice (i): http://mysite.org/members/emil http://mysite.org/members/emil/contact Not nice (ii): http://mysite.org/members/emil/ http://mysite.org/members/emil/contact/ Even worse (iii): http://mysite.org/members/emil etc Or worst (iv): http://mysite.orgmembersemil So, ideally I want the (ii) and (iii) and (iv) type of urls (with more slashes than needed) redirected to the first type of urls (with no trailing slash, and no duplicate slashes). For the duplicates I don't care that much, most important is the case (ii) with one trailing slash. And this is how I imagine this to work: - In addition to the existing option of append_slash, we get one more option, which is remove_slash. - With the setting enabled, for any given url there will be two versions computed: One reduced version without duplicates and without trailing slash, and one version without duplicates but with one trailing slash appended. - The dispatcher will give both versions a try. - If the original url had a trailing or duplicate slash, and no other redirect directive has been triggered, the request will be redirected to the reduced version. - If the original url was "clean", django can now execute the action determined by the dispatcher. I think this will be more useful than the append_slash mechanic. Thanks! donquixote --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
