The nginx documentation points to a reason:
https://nginx.org/en/docs/http/ngx_http_core_module.html#merge_slashes
Note that compression is essential for the correct matching of prefix
> string and regular expression locations. Without it, the
> “//scripts/one.php” request would not match
>
>
Hi Adam,
APPEND_SLASH only adds a slash at the end of the path
I'm more concerned about having multiple slashes in the middle of the path
I get your point about canonical URLs - I'm just confused why other major
HTTP servers are handling this different
On Wednesday, 4 March 2020 14:27:19 UTC-5,
I'd be against this
Merging multiple slashes is a way of duplicating canonical URL's for
things, something Django actively tries to avoid with APPEND_SLASHES.
If you want this functionality you should be able to create it yourself
with a custom URL converter or URLPattern subclass.
On Wed, 4 Mar
By the way, I also had a regression when upgrading to Django 2.1, which I
was not aware of until after about 4 or 5 weeks after I upgraded. Something
changed with the cookie settings (the default Django setting) and then
login/logout didn't work across 2 of my websites, until I changed cookie
setti
Right, but now we come right back to the beginning: it's not a regression,
and not judged one by Django i18n team, who are as knowledgeable as anyone
about these things. I see no value in your continuing to press this point.
If it had have been it would have been triaged as a Release Blocker.
Yes, I understand. Don't merge incorrect solutions. But notice that it is a
regression, in the affected languages. Things just stop working after
upgrading Django. If I didn't have the unit tests which failed, I might
have upgraded Django to production and my users would have received
messages in a
We are taking it seriously Uri. It’s difficult to resolve instantly when
there’s a super long mailing list thread, and several PRs in play, and a
major discussion on the ticket. It’s only recently that the correct
approach has become clear. It’s taken a community effort, from i18n experts
to get th
Hi,
I'd like to start a discussion about how django handles multiple slashes.
see: https://code.djangoproject.com/ticket/31319#comment:1
So far I can confirm that nginx, apache and unix folders handle multiple
slashes the same way (-> they get merged)
What's your (dev) opinion on this?
Cheers
B
Hi Carlton,
I think this issue is important for the Django developers mailing list. I
already commented on the PR about 3 weeks ago. Yes I know that most Django
users use either English, or a language which its plural forms were not
changed recently. But users who use a language whose plural forms
Thank you.
Oh, so this is what *backporting* means. In my attempts to understand
Django internals, I have been browsing around several tickets for some
weeks now and on some of them I read "Backporting " wondering
what that means 🙄
Thanks for helping me out in this regard too 🙂
On Wed, Mar 4, 2
I should have written: You can fork Django on GitHub, backport that commit
(git cherry-pick) to the stable/1.9.x branch, and install that hash:
https://adamj.eu/tech/2019/03/11/pip-install-from-a-git-repository/ .
On Wed, 4 Mar 2020 at 13:45, Deep Sukhwani wrote:
> Thank you, Adam,
>
> Note: For
Thank you, Adam,
Note: For future posts on this topic - Request you to use django-users
mailing list:
https://groups.google.com/forum/#!topic/django-users/GbU7FekodGY
I realized that I posted this in the wrong mailing list after posting it
and so I reposted this in django-users mailing list
<
HI Uri.
Yes, we know. :) Please don't bump. It's just adds noise. (If you MUST
bump, a comment on the PR is more than enough, so not everyone of the
thousands on this list needs a notification.) Thanks.
Ref backport: it's a possibility but you should phrase it more like, "this
is serious bug
Hi!
I'm pasting my "wrong mailing list" standard text below. This is a support
query for an old version of Django.
The ticket you linked to was committed in
https://github.com/django/django/commit/eedc88bd4a8468c2a0daa8346c9b57183dd77782
which I can see was released in Django 2.0.
You should rea
Well, hang on... that might be a bit quick.
I'm just thinking about putting together a call for Mentors this year.
I'm looking to do it via the Forum, which seems to be working well,
and we should be able to spread the load.
But we will need people formally in the Mentor role, and the number
Very well then. Thank you for the offer. However we do not have such need
at the moment.
On Tue, 3 Mar 2020, 10:03 pm Aakash Baranwal, wrote:
> No! I don't think so, that's exactly why I want to be a mentor.
>
> On Tue, 3 Mar, 2020, 11:26 PM Victor Egbe, wrote:
>
>> Sorry but do you not thi
Hello,
This query is for Django version 1.9 and Python 3.5 with Django Rest
Framework 3.5.4
*(I know this version is outdated, but moving ahead of this version as of
now is out of reach for the purpose of solving this query)*
*Exact Error observed:*
self.client.force_login(self.user)
Fil
Django developers,
PR #12332 is waiting to be reviewed and approved.
https://github.com/django/django/pull/12332
I would also like to suggest to include this PR, if accepted, into the next
version of 2.2. Otherwise I will not be able to use 2.2 or I will have to
fork Django to use 2.2, and then
Users don't need to confirm a logout. Confirmation is usually when deleting
a profile or making something irreversible. Logging out is reversible and
therefore doesn't need to be confirmed. Just clicking "logout" should log
the user out - whether a regular user or an admin.
אורי
u...@speedy.net
+1 from me
Afraid I don't know any of the why.
Also worth noting from the PR description:
Previously: DeferredAttributes would not get stapled onto models where the
> model (or an ancestor) already had an existing *non-falsey* attribute.
>
Non-falsey! I almost spat out my tea.
Thanks for the d
If your suggestion is limited to the admin, I think it would be fine, but
it's not necessary. But I don't think there is a compelling reason - there
aren't any difficulties with the CSS since Rene has already written it.
If your suggestion is for all logout views, there's no way to enforce it,
and
Why not have the logout link take the user to a page asking them to confirm the
logout, and have it as a POSTed form button from there?
That adds a helpful confirmation page, removes the difficulties of styling a
button as a link constantly (or changing the header design to a button).
One downs
Hi all.
Especially from those with long memories, can I request thoughts on a
proposed
adjustment to `Field.contribute_to_class()`, which affects the manner in
which
fields override attributes from parent classes?
The entails a breaking change. As such... 😬 — but I think it's acceptable
and
wo
Week ending March 1, 2020.
*Triaged:*
https://code.djangoproject.com/ticket/31296 - Document different config
scenarios of full text search configuration. (wontfix)
https://code.djangoproject.com/ticket/31303 - Remove outdated note about
symmetrical with m2m relationship from a model to itself.
Details are available on the Django project weblog:
https://www.djangoproject.com/weblog/2020/mar/04/security-releases/
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubscribe from this group and st
25 matches
Mail list logo
