id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
32106	Redirect following in test client does not correctly set HTTP_HOST	Brenton Partridge	bcail	"Testing breaks when the following are true, which might be the case when testing e.g. the content resulting from a deep link from one Site to another Site:

- django.test.Client is constructed with HTTP_HOST explicitly set to Hostname 1
- a 301/302 response redirects to a URL with Hostname 2
- follow=True

Expected behavior is that, in the view logic handling the follow, request.get_host() would return Hostname 2.

But actual behavior is that, in the view logic handling the follow, request.get_host() would return Hostname 1.

This is because django.test.Client._handle_redirects only sets SERVER_NAME on its recursive "".get"" call, not HTTP_HOST. Therefore, the WSGIRequest would have HTTP_HOST still set from the defaults from the Client constructor, and request._get_raw_host() checks HTTP_HOST before SERVER_NAME.

And yet one would expect HTTP_HOST to be the one set, as this would mimic a user agent setting the Host request header based on the Location response header from the 301/302.

https://github.com/django/django/blob/stable/3.1.x/django/test/client.py#L820

This can be mitigated by never using HTTP_HOST in test code, instead setting SERVER_NAME in the Client constructor; alternately, it can be sidestepped by setting follow=False and manually creating a new Client to make the follow request.

Fix considerations:

Users may have previously come to rely on SERVER_NAME being set here, so perhaps the right fix would be to set both HTTP_HOST and SERVER_NAME to the new hostname.

But if full backwards compatibility is desired, at the very least there should be documentation to recommend against using HTTP_HOST as a keyword argument to django.test.Client."	Bug	closed	Testing framework	3.1	Normal	fixed		bcail	Ready for checkin	1	0	0	0	0	0