-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Default Content-Type header re-applied when using test client #2450
Comments
Seems like setting |
@davidism I'm happy to submit a PR, but as far as I can see (On the latest 'main' branch for flask), the 'app.test_client' defined here still passes the Flask.Response as second argument to the FlaskClient, which in term passes the 'Flask.Response' as the second argument to werkzeug.test.Client, meaning the Flask.Response is the second base class when the 'WrapperTestResponse' is constructed, in term the default_mimetype from Flask.Response is used for the WrapperTestResponse (see here), or am I missing something? If the above is the case, the fix should be inside the 'flask' repo, e.g. by changing line 1067 - 1069 in app.test_client() to: return cls( # type: ignore
self, type('AppTestResponse', (self.response_class,), {'default_mimetype': None}), use_cookies=use_cookies, **kwargs
) Please let me know your thoughts on this! Note that this issue is about the way it's used by Flask. As you mention, the same issue may occur when using purely WerkZeug, and initializing the test.client with response_wrapper = None. In that case the TestResponse class from Werkzeug is used, which also has a default mimetype, but then set to text/plain, rather than the text/html that I'm seeing... |
The TestResponse should have a mimetype as defined by the response itself. If the response is missing a mimetype then it shouldn't assume one. See pallets#2450
The TestResponse should have a mimetype as defined by the response itself. If the response is missing a mimetype then it shouldn't assume one. See pallets#2450
The TestResponse should have a mimetype as defined by the response itself. If the response is missing a mimetype then it shouldn't assume one. See pallets#2450
The TestResponse should have a mimetype as defined by the response itself. If the response is missing a mimetype then it shouldn't assume one. See pallets#2450
The TestResponse should have a mimetype as defined by the response itself. If the response is missing a mimetype then it shouldn't assume one. See #2450
When using 'make_response' in a view function, default headers can be cleared, such as the default 'Content-Type' header. This works fine when using
flask run
, but when using the test client, the default 'Content-Type' header is re-applied, causing the test response to be different from the actual server response.Current Behaviour
Given the following flask app (test_app.py):
When you do
flask run
in one terminal window, and curl in another, the output is as expected (No Content-Type header):When you run the application standalone, so the test client is triggered however, the default flask 'Content-Type' header is applied:
Expected behavior
I expect, if default headers are cleared in the view function, that they are not re-applied by the test client, especially since this doesn't match the actual response of the server.
Environment:
Python 3.10.5
Flask 2.1.2
Werkzeug 2.1.2
Cause
The
test_client
method initializes the FlaskClient class withself.response_class
(flask.wrappers.Response), which in term passes this as a 'response_wrapper' to the werkzeug.test.Client__init__
method. Sinceflask.wrappers.Response.default_mimetype
has the value seen above, this is always applied to a test_client response in case there's no 'Content-Type' header.The text was updated successfully, but these errors were encountered: