[Django] #25878: Django 1.9 works well in Debug=True, but doesn't redirect unslash urls into slashed one in Debug=False
Django
slashed one in Debug=False
-------------------------------+-------------------------
Reporter: kuna | Owner: nobody
Type: Uncategorized | Status: new
Component: HTTP handling | Version: 1.9
Severity: Normal | Keywords: slash,debug
Triage Stage: Unreviewed | Has patch: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------+-------------------------
I first uploaded it to google groups but I don't find where's my article
is (I'm not get used to it) so I decided to make a ticket here.
as I mentioned in title, django 1.9's url slash redirection doesn't
working well in debug=False. APPEND_SLASH was no effect. but in
debug=True, it does well, and only these 'cached(loaded in debug mode)'
url redirects well even in debug=False. (I don't know it's browser
redirection or django's work ...)
anyway, I fixed django/middleware/common.py like this and works well.
original code was rather a little strange, as I thought.
{{{
def process_request(self, request):
"""
Check for denied User-Agents and rewrite the URL based on
settings.APPEND_SLASH and settings.PREPEND_WWW
"""
# Check for denied User-Agents
if 'HTTP_USER_AGENT' in request.META:
for user_agent_regex in settings.DISALLOWED_USER_AGENTS:
if
user_agent_regex.search(request.META['HTTP_USER_AGENT']):
raise PermissionDenied('Forbidden user agent')
# Check for a redirect based on settings.PREPEND_WWW
host = request.get_host()
if settings.PREPEND_WWW and host and not host.startswith('www.'):
host = 'www.' + host
# Check if we also need to append a slash so we can do it all
# with a single redirect.
if self.should_redirect_with_slash(request):
path = self.get_full_path_with_slash(request)
return self.response_redirect_class('%s://%s%s' %
(request.scheme, host, path))
}}}
Hope this issue can be meaningful.
thanks for reading
--
Ticket URL: <https://code.djangoproject.com/ticket/25878>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
slashed one in Debug=False
Reporter: kuna | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 1.9
Keywords: slash,debug | Triage Stage: Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by kuna):
* needs_better_patch: => 0
* type: Uncategorized => Bug
* needs_tests: => 0
* needs_docs: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:1>
Django
slashed one in Debug=False
Reporter: kuna | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 1.9
Keywords: slash,debug | Triage Stage: Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Description changed by kuna:
Old description:
New description:
I first uploaded it to google groups but I don't find where's my article
is (I'm not get used to it) so I decided to make a ticket here.
as I mentioned in title, django 1.9's url slash redirection doesn't
working well in debug=False. APPEND_SLASH was no effect. but in
debug=True, it does well, and only these 'cached(loaded in debug mode)'
url redirects well even in debug=False. (I don't know it's browser
redirection or django's work ...)
anyway, I fixed django/middleware/common.py like this and works well.
original code was rather a little strange, as I thought.
{{{
def process_request(self, request):
"""
Check for denied User-Agents and rewrite the URL based on
settings.APPEND_SLASH and settings.PREPEND_WWW
"""
# Check for denied User-Agents
if 'HTTP_USER_AGENT' in request.META:
for user_agent_regex in settings.DISALLOWED_USER_AGENTS:
if
user_agent_regex.search(request.META['HTTP_USER_AGENT']):
raise PermissionDenied('Forbidden user agent')
# Check for a redirect based on settings.PREPEND_WWW
host = request.get_host()
redirect = False
if settings.PREPEND_WWW and host and not host.startswith('www.'):
host = 'www.' + host
redirect = True
# Check if we also need to append a slash so we can do it all
# with a single redirect.
if self.should_redirect_with_slash(request):
path = self.get_full_path_with_slash(request)
redirect = True
else:
path = request.get_full_path()
if (redirect):
return self.response_redirect_class('%s://%s%s' %
(request.scheme, host, path))
}}}
Hope this issue can be meaningful.
thanks for reading
PS changed a little - previous code won't work with prepending WWW
--
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:2>
Django
-------------------------------+--------------------------------------
Reporter: kuna | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 1.9
Keywords: slash,debug | Triage Stage: Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Comment (by timgraham):
Could you be a little more specific with the steps to reproduce the error,
perhaps providing a sample project or a regression test for Django? Your
suggested changes don't pass the current tests (failures in `middleware`).
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:3>
Django
-------------------------------+--------------------------------------
Type: Bug | Status: new
Component: HTTP handling | Version: 1.9
Keywords: slash,debug | Triage Stage: Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Comment (by kuna):
Replying to [comment:3 timgraham]:
> Could you be a little more specific with the steps to reproduce the
error, perhaps providing a sample project or a regression test for Django?
Your suggested changes don't pass the current tests (failures in
`middleware`).
My project is [https://github.com/kuna/iidxranktable here] and
[http://insane.pe.kr/iidx/ 'currently running']. Changed code is applied
to my project currently and running well. I don't know well about django's
module test or deep hierarchy of django module, so I need to find more
about them if I have to fix this problem fully correctly. I'll comment
more when I find something new about it.
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:4>
Django
-------------------------------+--------------------------------------
Type: Bug | Status: new
Component: HTTP handling | Version: 1.9
Keywords: slash,debug | Triage Stage: Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Old description:
> I first uploaded it to google groups but I don't find where's my article
> is (I'm not get used to it) so I decided to make a ticket here.
>
> as I mentioned in title, django 1.9's url slash redirection doesn't
> working well in debug=False. APPEND_SLASH was no effect. but in
> debug=True, it does well, and only these 'cached(loaded in debug mode)'
> url redirects well even in debug=False. (I don't know it's browser
> redirection or django's work ...)
>
> anyway, I fixed django/middleware/common.py like this and works well.
> original code was rather a little strange, as I thought.
>
> {{{
> def process_request(self, request):
> """
> Check for denied User-Agents and rewrite the URL based on
> settings.APPEND_SLASH and settings.PREPEND_WWW
> """
>
> # Check for denied User-Agents
> if 'HTTP_USER_AGENT' in request.META:
> for user_agent_regex in settings.DISALLOWED_USER_AGENTS:
> if
> user_agent_regex.search(request.META['HTTP_USER_AGENT']):
> raise PermissionDenied('Forbidden user agent')
>
> # Check for a redirect based on settings.PREPEND_WWW
> host = request.get_host()
>
> redirect = False
> if settings.PREPEND_WWW and host and not host.startswith('www.'):
> host = 'www.' + host
> redirect = True
>
> # Check if we also need to append a slash so we can do it all
> # with a single redirect.
> if self.should_redirect_with_slash(request):
> path = self.get_full_path_with_slash(request)
> redirect = True
> else:
> path = request.get_full_path()
>
> if (redirect):
> return self.response_redirect_class('%s://%s%s' %
> (request.scheme, host, path))
> }}}
>
>
> Hope this issue can be meaningful.
>
> thanks for reading
>
> PS changed a little - previous code won't work with prepending WWW
New description:
I first uploaded it to google groups but I don't find where's my article
is (I'm not get used to it) so I decided to make a ticket here.
as I mentioned in title, django 1.9's url slash redirection doesn't
working well in debug=False. APPEND_SLASH was no effect. but in
debug=True, it does well, and only these 'cached(loaded in debug mode)'
url redirects well even in debug=False. (I don't know it's browser
redirection or django's work ...)
anyway, I fixed django/middleware/common.py like this and works well.
original code was rather a little strange, as I thought.
{{{
def process_request(self, request):
"""
Check for denied User-Agents and rewrite the URL based on
settings.APPEND_SLASH and settings.PREPEND_WWW
"""
# Check for denied User-Agents
if 'HTTP_USER_AGENT' in request.META:
for user_agent_regex in settings.DISALLOWED_USER_AGENTS:
if
user_agent_regex.search(request.META['HTTP_USER_AGENT']):
raise PermissionDenied('Forbidden user agent')
# Check for a redirect based on settings.PREPEND_WWW
redirect = False
host = request.get_host()
if settings.PREPEND_WWW and host and not host.startswith('www.'):
redirect = True
host = 'www.' + host
# Check if we also need to append a slash so we can do it all
# with a single redirect.
if self.should_redirect_with_slash(request):
redirect = True
path = self.get_full_path_with_slash(request)
else:
path = request.get_full_path()
if (redirect):
return self.response_redirect_class('%s://%s%s' %
(request.scheme, host, path))
}}}
Hope this issue can be meaningful.
thanks for reading
PS changed a little - previous code won't work with prepending WWW
--
Comment (by kuna):
I did test and look at the code, and I have question to the behavior.
I found failed test {{{ test_non_ascii_query_string_does_not_crash }}},
and It requires {{{ http://testserver/slash/?drink=caf%C3%A9 }}} to be
redirected(301). I think It doesn't need to be, as there's no need to
prepend WWW(False default) and redirect with slash.
I think the test should changed to {{{ self.assertEqual(r.status_code,
None) }}}, not 301.
and one more thing - this bug has occurred since I upgraded django from
1.8.7 to 1.9. I'm inspecting more about this.
thanks for your sincere.
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:5>
Django
-------------------------------+--------------------------------------
Type: Bug | Status: new
Component: HTTP handling | Version: 1.9
Keywords: slash,debug | Triage Stage: Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Comment (by kuna):
I found why this occurs: there was erroneous {{{ 404.html }}} file in my
{{{ ./(appname)/templates }}} directory, and that template file was loaded
when unslashed URL called which called {{{ page_not_found }}} in {{{
views/defaults.py }}}. But I think that shouldn't happened as it's
unexpected behavior. Also, rendering template even in case of redirection
is definitely a resource waste, I think.
That wasn't happened in django 1.8.7.
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:6>
Django
erroneous
-------------------------------+--------------------------------------
Reporter: kuna | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 1.9
Keywords: slash,debug | Triage Stage: Unreviewed
Needs tests: 0 | Patch needs improvement: 0
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:7>
Django
erroneous
-------------------------------+--------------------------------------
Type: Bug | Status: new
Component: HTTP handling | Version: 1.9
Keywords: slash,debug | Triage Stage: Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Comment (by timgraham):
Can you [https://docs.djangoproject.com/en/dev/internals/contributing
/triaging-tickets/#bisecting-a-regression bisect] to find the commit where
the behavior changed? Could you put together a minimal project that
reproduces the problem? I am not sure whether this is a bug in Django or a
problem with your application.
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:8>
Django
erroneous
-------------------------------+--------------------------------------
Type: Bug | Status: new
Component: HTTP handling | Version: 1.9
Keywords: slash,debug | Triage Stage: Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Comment (by kuna):
It was caused by my projects buggy template, but behavior changed since
django version was updated. So It's no use to do git bisect. I'm also
confused it's bug or just a simple behavior change...
[https://dl.dropboxusercontent.com/u/102712785/django19.zip Download] and
unzip this project and check not working APPEND_SLASH when Debug=False
with this project under django v1.9.
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:9>
Django
erroneous
-------------------------------+--------------------------------------
Type: Bug | Status: new
Component: HTTP handling | Version: 1.9
Keywords: slash,debug | Triage Stage: Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Changes (by timgraham):
* cc: electricjay (added)
Comment:
The change is bisected to 434d309ef6dbecbfd2b322d3a1da78aa5cb05fa8
(#24720). As you said, I think something doesn't seem quite right if we
have to render the 404 page before redirecting. Jay, as the author of the
original patch could you let us know your thoughts?
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:10>
Django
erroneous
-------------------------------+--------------------------------------
Type: Bug | Status: new
Component: HTTP handling | Version: 1.9
Keywords: slash,debug | Triage Stage: Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Comment (by electricjay):
Rendering the 404 template before redirection is an unfortunate side
effect of the above mentioned patch. Fortunately the overhead this
rendering is very minor compared to the overhead of a client side
redirect.
I think the developer overhead of understanding what is happening when
things wrong in the 404 rendering is not nearly so minor.
Ideally the 404 would be caught before the template is rendered, but my
recollection is that 404 exceptions are not sent through the
//process_exception// middleware
In my opinion the cleanest solution would be to feed all exceptions
through the //process_exception// middleware, and then modify the common
middleware to take advantage of this. There would however be some risk of
this interacting badly with existing //process_exception// middleware.
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:11>
Django
erroneous
Reporter: kuna | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 1.9
Keywords: slash,debug | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Changes (by timgraham):
* severity: Normal => Release blocker
* stage: Unreviewed => Accepted
Comment:
kuna, your patch might be okay. There are two other test failure in
`admin_views` and `i18n`, but they might just be tests that need to be
adapted. Are you able to convert your patch into a pull request?
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:12>
Django
erroneous
---------------------------------+------------------------------------
Type: Bug | Status: new
Component: HTTP handling | Version: 1.9
Keywords: slash,debug | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* needs_tests: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:13>
Django
erroneous
---------------------------------+------------------------------------
Type: Bug | Status: new
Component: HTTP handling | Version: 1.9
Keywords: slash,debug | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 0
Comment (by tripples):
I was facing same issue after upgrading to Django 1.9. When DEBUG=False
redirection was not happening. Applied above patch manually on production
system. Helped for me.
Case 1(Issue):
When DEBUG=False,
example.com/sample
Returns 404.
Case 2:
Whereas with DEBUG=True
example.com/sample/
Return 301
Thanks,
Sanket
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:14>
Django
erroneous
Reporter: kuna | Owner: timgraham
Type: Bug | Status: assigned
Component: HTTP handling | Version: 1.9
Keywords: slash,debug | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 0
Changes (by timgraham):
* owner: nobody => timgraham
* status: new => assigned
Comment:
Got an initial [https://github.com/django/django/pull/5903 PR] up, but
need to add another test.
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:15>
Django
erroneous
---------------------------------+-------------------------------------
Reporter: kuna | Owner: timgraham
Type: Bug | Status: assigned
Keywords: slash,debug | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 0
Comment (by pulsedemon):
I just upgraded to 1.9 today and am having the same problem. Tested your
PR and it works for me fyi
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:16>
Django
erroneous
---------------------------------+-------------------------------------
Reporter: kuna | Owner: timgraham
Type: Bug | Status: assigned
Keywords: slash,debug | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 0
Comment (by timgraham):
@tripples, @pulsedemon, do you have incorrect 404 templates? I'm not sure
it's the same issue because in the original report, with `DEBUG=False` an
incorrect URL will return a 500, not a 404, since the 404 template can't
be rendered. If you could provide a sample project to reproduce, that
would be helpful.
After understanding the issue a bit more, I think the proposed patch
basically reverts #24720 and the benefit it provides. Obviously correct
behavior trumps performance, but if an invalid 404 template is the only
way to trigger it, then maybe we can find a way to fix this without
reverting it.
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:17>
Django
erroneous
---------------------------------+-------------------------------------
Reporter: kuna | Owner: timgraham
Type: Bug | Status: assigned
Keywords: slash,debug | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 0
Comment (by pulsedemon):
@timgraham I did have a problem with my 404 template, which I didn't
realize until I saw this ticket. I had a custom 404 handler and it was
not setting a 404 status_code. So because it was returning 200,
APPEND_SLASH was never activated.
The template itself worked fine, it was just the status_code causing
problems.
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:18>
Django
erroneous
---------------------------------+-------------------------------------
Reporter: kuna | Owner: timgraham
Type: Bug | Status: assigned
Keywords: slash,debug | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 0
Comment (by timgraham):
Thanks for that info. At this point then, I'm inclined to discard my
initial patch and instead add a mention in the release notes about this as
well as to try to improve the error reporting situation. To address the
situation in comment 18, an idea is to log a warning in
[https://github.com/django/django/blob/98839e906632dfe77c6f6906d61d62868a0541dc/django/core/handlers/base.py#L86-L93
BaseHander.get_exception_response()] if the error handler returns a
response with the incorrect status code. I haven't thought through if
there could be a valid reason for returning a different code, but
automatically setting the code could be a bit risky for a patch that's
backported to a stable branch. I'll have to look to see if we can do any
better about the situation where the 404 template doesn't render correctly
as reported in the ticket description.
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:19>
Django
erroneous
---------------------------------+-------------------------------------
Reporter: kuna | Owner: timgraham
Type: Bug | Status: assigned
Keywords: slash,debug | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 0
Comment (by tripples):
@timgraham I have exact case like @pulsedemon. My 404 handler was
returning 200 status code instead of 404. However, I have tried
APPEND_SLASH=True and even with APPEND_SLASH=True it was not hitting
correct required response. Only difference I was noticing was, with
DEBUG=True I was hitting correct response.
1. DEBUG=True
Always gives correct response.
2. DEUBG=FalseAPPEND_SLASH not set.
OR DEBUG = False and APPEND_SLASH set.
Returning 404 handler with status code 200.
I will check if I can get sample project for reproducing issue.
Also minor query, does Site models or related settings can have any
impact in this issue?
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:20>
Django
erroneous
---------------------------------+-------------------------------------
Reporter: kuna | Owner: timgraham
Type: Bug | Status: assigned
Keywords: slash,debug | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Changes (by timgraham):
* has_patch: 1 => 0
* needs_tests: 1 => 0
Comment:
Right, so with 434d309ef6dbecbfd2b322d3a1da78aa5cb05fa8 (#24720) your
`handler404` (which is only used when `DEBUG=False`, must return a 404
status code, otherwise `APPEND_SLASH` won't work correctly. I don't think
this is an unreasonable requirement, but it needs to be mentioned in the
1.9 release notes as a backwards-incompatible change (unless someone
thinks this needs to go through a deprecation path and thus we should
revert the original patch on 1.9). We could add logging as I mentioned in
comment 19 to help developers find this mistake in their handler.
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:21>
Django
erroneous
---------------------------------+-------------------------------------
Reporter: kuna | Owner: timgraham
Type: Bug | Status: assigned
Keywords: slash,debug | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Comment (by tripples):
Thanks, tim. Adding some django checks for these handlers or logging would
really help.
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:22>
Django
erroneous
---------------------------------+-------------------------------------
Reporter: kuna | Owner: timgraham
Type: Bug | Status: assigned
Keywords: slash,debug | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Comment (by pulsedemon):
Replying to [comment:21 timgraham]:
> Right, so with 434d309ef6dbecbfd2b322d3a1da78aa5cb05fa8 (#24720) your
`handler404` (which is only used when `DEBUG=False`, must return a 404
status code, otherwise `APPEND_SLASH` won't work correctly. I don't think
this is an unreasonable requirement, but it needs to be mentioned in the
1.9 release notes as a backwards-incompatible change (unless someone
thinks this needs to go through a deprecation path and thus we should
revert the original patch on 1.9). We could add logging as I mentioned in
comment 19 to help developers find this mistake in their handler.
I think a warning and comment about this in the release
notes/documentation is good enough personally. It's not unreasonable to
expect the status_code be set manually when implementing a custom handler.
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:23>
Django
erroneous
---------------------------------+-------------------------------------
Reporter: kuna | Owner: timgraham
Type: Bug | Status: assigned
Keywords: slash,debug | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Changes (by timgraham):
* has_patch: 0 => 1
Comment:
[https://github.com/django/django/pull/5932 PR] to add the requirement to
the 1.9 release notes and docs.
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:24>
Django
erroneous
---------------------------------+-------------------------------------
Reporter: kuna | Owner: timgraham
Component: HTTP handling | Version: 1.9
Keywords: slash,debug | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Changes (by Tim Graham <timograham@…>):
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"49eeb0f570c91af5064d9e4ac8649e9afa0236ec" 49eeb0f5]:
{{{
#!CommitTicketReference repository=""
revision="49eeb0f570c91af5064d9e4ac8649e9afa0236ec"
Fixed #25878 -- Documented requirement that handler404 return a 404
response.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:25>
Django
erroneous
---------------------------------+-------------------------------------
Reporter: kuna | Owner: timgraham
Type: Bug | Status: closed
Component: HTTP handling | Version: 1.9
Severity: Release blocker | Resolution: fixed
Keywords: slash,debug | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+-------------------------------------
Comment (by Tim Graham <timograham@…>):
In [changeset:"35fd2a6fd53c758b9804596dd0e81f5bd71e7ea5" 35fd2a6f]:
{{{
#!CommitTicketReference repository=""
revision="35fd2a6fd53c758b9804596dd0e81f5bd71e7ea5"
[1.9.x] Fixed #25878 -- Documented requirement that handler404 return a
404 response.
Backport of 49eeb0f570c91af5064d9e4ac8649e9afa0236ec from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:26>
Django
erroneous
---------------------------------+-------------------------------------
Reporter: kuna | Owner: timgraham
Type: Bug | Status: closed
Component: HTTP handling | Version: 1.9
Severity: Release blocker | Resolution: fixed
Keywords: slash,debug | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+-------------------------------------
Comment (by jamesbeith):
Does this affect the `django.views.csrf.csrf_failure` view as well? As in,
if the user sets their own view using the `CSRF_FAILURE_VIEW` setting then
that view must return a `HttpResponseForbidden`? If so then it might be
worth adding that to the
[https://docs.djangoproject.com/en/1.9/ref/settings/#csrf-failure-view
csrf-failure-view settings docs] similar to what was done in this
[https://github.com/django/django/pull/5932 PR].
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:27>
Django
erroneous
---------------------------------+-------------------------------------
Reporter: kuna | Owner: timgraham
Type: Bug | Status: closed
Component: HTTP handling | Version: 1.9
Severity: Release blocker | Resolution: fixed
Keywords: slash,debug | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+-------------------------------------
Comment (by Tim Graham <timograham@…>):
In [changeset:"62e83c71d2086b91d58c313e46933ef7aa8b6db1" 62e83c7]:
{{{
#!CommitTicketReference repository=""
revision="62e83c71d2086b91d58c313e46933ef7aa8b6db1"
Refs #25878 -- Added the expected return type of CSRF_FAILURE_VIEW.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:28>
Django
erroneous
---------------------------------+-------------------------------------
Reporter: kuna | Owner: timgraham
Type: Bug | Status: closed
Component: HTTP handling | Version: 1.9
Severity: Release blocker | Resolution: fixed
Keywords: slash,debug | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+-------------------------------------
Comment (by Tim Graham <timograham@…>):
In [changeset:"c74b1b408a3ccdc1f1c199e709f7c825644f1a9e" c74b1b4]:
{{{
#!CommitTicketReference repository=""
revision="c74b1b408a3ccdc1f1c199e709f7c825644f1a9e"
[1.9.x] Refs #25878 -- Added the expected return type of
CSRF_FAILURE_VIEW.
Backport of 62e83c71d2086b91d58c313e46933ef7aa8b6db1 from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25878#comment:29>