[Django] #27760: Hard to diagnose reason for 400 response when making test request that sets SERVER_NAME

22 views
Skip to first unread message

Django

unread,
Jan 22, 2017, 5:27:56 PM1/22/17
to django-...@googlegroups.com
#27760: Hard to diagnose reason for 400 response when making test request that sets
SERVER_NAME
---------------------------------------------+------------------------
Reporter: Peter Inglesby | Owner: nobody
Type: Uncategorized | Status: new
Component: Testing framework | Version: 1.10
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
---------------------------------------------+------------------------
Since #26666 was fixed, requests made with the test client that set
`SERVER_NAME` will return a 400, where the body of the response is simply
"<h1>Bad Request (400)</h1>".

To work out what's gone wrong, you have to grep the Django source code for
`Bad Request`. Could there be a better way to communicate the cause of
the problem?

--
Ticket URL: <https://code.djangoproject.com/ticket/27760>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Jan 23, 2017, 10:15:17 AM1/23/17
to django-...@googlegroups.com
#27760: Hard to diagnose reason for 400 response when making test request that sets
SERVER_NAME
-----------------------------------+--------------------------------------

Reporter: Peter Inglesby | Owner: nobody
Type: Uncategorized | Status: new
Component: Testing framework | Version: 1.10
Severity: Normal | Resolution:

Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+--------------------------------------

Comment (by Tim Graham):

I think you can use the `manage.py test --debug-mode` option added in
#27008 to get the detailed exception page.

--
Ticket URL: <https://code.djangoproject.com/ticket/27760#comment:1>

Django

unread,
Jan 23, 2017, 11:51:32 AM1/23/17
to django-...@googlegroups.com
#27760: Hard to diagnose reason for 400 response when making test request that sets
SERVER_NAME
-----------------------------------+--------------------------------------

Reporter: Peter Inglesby | Owner: nobody
Type: Uncategorized | Status: new
Component: Testing framework | Version: 1.10
Severity: Normal | Resolution:

Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+--------------------------------------

Comment (by Peter Inglesby):

Running the test with `--debug-mode` does tell you what the problem is,
but it's only useful if you know that it exists, and even then it's not
obvious that it would help.

I've been poking around core/handlers/exception.py, and was able to get
the behaviour I'm after by adding
`signals.got_request_exception.send(sender=None, request=request)` to the
`SuspiciousOperation` branch of `response_for_exception`. Would this be a
viable approach?

--
Ticket URL: <https://code.djangoproject.com/ticket/27760#comment:2>

Django

unread,
Jan 23, 2017, 1:10:00 PM1/23/17
to django-...@googlegroups.com
#27760: Hard to diagnose reason for 400 response when making test request that sets
SERVER_NAME
-----------------------------------+--------------------------------------

Reporter: Peter Inglesby | Owner: nobody
Type: Uncategorized | Status: new
Component: Testing framework | Version: 1.10
Severity: Normal | Resolution:

Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+--------------------------------------

Comment (by Tim Graham):

A discussion on the DevelopersMailingList would be needed to see if
there's consensus to make a backwards-incompatible change there. The
current behavior is
[https://docs.djangoproject.com/en/dev/topics/testing/tools/#exceptions
documented]. The commit that introduced that signal is
f9cdde0cb41851e9d1eb70bd108debb75f267585.

--
Ticket URL: <https://code.djangoproject.com/ticket/27760#comment:3>

Django

unread,
Jan 24, 2017, 11:26:42 AM1/24/17
to django-...@googlegroups.com
#27760: Hard to diagnose reason for 400 response when making test request that sets
SERVER_NAME
-------------------------------------+-------------------------------------

Reporter: Peter Inglesby | Owner: nobody
Type: | Status: new
Cleanup/optimization |

Component: Testing framework | Version: 1.10
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Someday/Maybe

Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Tim Graham):

* type: Uncategorized => Cleanup/optimization
* stage: Unreviewed => Someday/Maybe


--
Ticket URL: <https://code.djangoproject.com/ticket/27760#comment:4>

Django

unread,
Mar 20, 2020, 12:06:17 PM3/20/20
to django-...@googlegroups.com
#27760: Hard to diagnose reason for 400 response when making test request that sets
SERVER_NAME
-------------------------------------+-------------------------------------

Reporter: Peter Inglesby | Owner: nobody
Type: | Status: new
Cleanup/optimization |

Component: Testing framework | Version: 1.10
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Someday/Maybe
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Petr Dlouhý):

To anyone bumping into this. I was able to determine the cause of the Bad
request by adding

{{{
@override_settings(
DEBUG=True,
)
}}}

decorator to the test class and then printing the response into file with


{{{
with open("response.html", "w") as f:
f.write(response.content.decode())
}}}

And the error was, that I hadn't test server url in `ALOWED_HOSTS`.

--
Ticket URL: <https://code.djangoproject.com/ticket/27760#comment:5>

Reply all
Reply to author
Forward
0 new messages