Re: APPEND_SLASH behavior

> > To avoid the problems with the bad interaction with the request machinery, > another approach that came to mind would be to allow inserting / including > a function at any point in the URLconf. The function would return whether > the pattern should be skipped or claimed. That would have the adv

Re: APPEND_SLASH behavior

Hi Chris, nice hearing from you. On Friday, May 7, 2021 at 6:20:44 PM UTC+2 chris.j...@gmail.com wrote: > With the suggested work-around of having a view call other views, would a > view be able to continue URL resolution in that case? > Not without many code changes I fear and I am not sure

Re: APPEND_SLASH behavior

On Thursday, May 6, 2021 at 10:19:42 PM UTC+2 Adam Johnson wrote: > That said, I think doing this in process_response would be preferable over >> doing it in process_request so the extra checks when the URL is valid (the >> common case) are reduced. Resolving URLs can take a bit, especially wh

Re: APPEND_SLASH behavior

On Thursday, May 6, 2021 at 10:32:59 AM UTC-7 f.apo...@gmail.com wrote: > I took a quick glance (literally just that) at the pull requests. I do > like the one that offers a way to abort early inside a prefix -- this is a > nice optimization and as well might open interesting options for > spec

Re: APPEND_SLASH behavior

> > That said, I think doing this in process_response would be preferable over > doing it in process_request so the extra checks when the URL is valid (the > common case) are reduced. Resolving URLs can take a bit, especially when > the urlconf is long and as such I'd like to get that check out of

Re: APPEND_SLASH behavior

Hi, thanks for giving it a look. The PR are based on existing tickets so these are not my ideas. The relevant ticket for the backtracking URL contains valuable information about its benefits and why the author requested the feature. The idea is to

Re: APPEND_SLASH behavior

Hi, I took a quick glance (literally just that) at the pull requests. I do like the one that offers a way to abort early inside a prefix -- this is a nice optimization and as well might open interesting options for specialized catch all views. I am not convinced about the backtracking PR, which

Re: APPEND_SLASH behavior

Ok I see better. Talking about efficiency, I take this opportunity to link here the following draft PR I made: Backtracking URL Resolver and Provide ability to abort URL resolution early , which, if imple

Re: APPEND_SLASH behavior

On Thursday, April 29, 2021 at 4:23:57 PM UTC+2 atd...@gmail.com wrote: > In both cases however, the current check being done in the > process_response method for the CommonMiddleware(here >

Re: APPEND_SLASH behavior

It seems that my first link doesn't work. I was saying that I ran the coverage of the project and found that this line(here ) is never hit because the two conditions can never

Re: APPEND_SLASH behavior

Yes I suggested doing that work at the middleware level, but it's not the preferred solution due to maintanability concerns. However, you haven't mentionned the unneccesary check (I think) being done in the CommonMiddleware's process_response method ? Le jeudi 29 avril 2021 à 21:54:02 UTC+2,

Re: APPEND_SLASH behavior

I don't think Django should change here. The current APPEND_SLASH behaviour is conservative and expected. Django can't tell the difference between a catch-all view that "shouldn't really catch the URL", and any other view. Notably your suggestion would undo the work in django 3.2 to add a catch-al

APPEND_SLASH behavior

Hello, I posted this on #django-users but I think here is the right place to post it. To give more context, this is the related issue on Wagtail which lead me here. In gener

Re: Backward-incompatible change to APPEND_SLASH behavior

On Wed, 2007-12-19 at 09:01 -0500, Forest Bond wrote: > Hi, > > I ran into a backwards-incompatible change related to changing behavior of > APPEND_SLASH: > > http://code.djangoproject.com/changeset/6852 > > I had some URL patterns in my urlconf that matched URLs with and without a > trailing

Backward-incompatible change to APPEND_SLASH behavior

Hi, I ran into a backwards-incompatible change related to changing behavior of APPEND_SLASH: http://code.djangoproject.com/changeset/6852 I had some URL patterns in my urlconf that matched URLs with and without a trailing slash. Previously, these would always get redirected to the version with