Consider SCRIPT_NAME for SECURE_REDIRECT_EXEMPT setting

[Jonas Haag]

Similar to #25598, SCRIPT_NAME should be considered for SECURE_REDIRECT_EXEMPT as well.

Generally speaking, there should be consistent handling of SCRIPT_NAME in the settings -- either consider it for all settings or for none.

[Tim Graham]

I guess the idea would be to use request.path_info instead of request.path in the ​SecurityMiddleware?

Can you elaborate on the use case and how the behavior will change? Could the change break existing working configurations?

[Jonas Haag]

See #25598 for discussion of the use case (the setting should be independent from the subpath the application is mounted at). This breaks existing sites, yes. I haven't had a look into the implementation.

[Sniom]

I've got the same use case :
I set SCRIPT_NAME to "/some_script_name".

At first I wanted ​http://url.com/some_script_name/exempt1 and ​http://url.com/some_script_name/exempt2 to be served via http.
So I set SECURE_REDIRECT_EXEMPT=[r"^exempt1$", "^exempt2$""]

It took me some time to figure out that SECURE_REDIRECT_EXEMPT was not taking into account SCRIPT_NAME
I had to modify SECURE_REDIRECT_EXEMPT to [r"^some_script_name/exempt1$", r"^some_script_name/exempt2$"]

Seems to me that using request.path_info rather than request.path would do the trick.
But changing that would break existing sites using SCRIPT_NAME + SECURE_REDIRECT_EXEMPT

Should we at least document this strange behaviour in ​https://docs.djangoproject.com/en/6.0/ref/settings/#secure-redirect-exempt ?

(I am using django version 6.0.5)

[gaweng]

​https://github.com/django/django/pull/21367

[blighj]

The PR is marked as a draft on github, I'm going to take that as a signal that it is not ready for review yet. So I'm checking patch needs improvement to take it out of the review queue. If it is ready for review go ahead mark it as ready on github and I'll jump in.