TODO: We could raise SupiciousOperation here if the port is empty (ie the hostname ended with :)

since there's no validation here and get_port() is relying on this code I would think you'd need to consider other malformed cases, such as example.com:abc or 1.1.1.1:443]

Yeah I am leaning toward calling int on the port part as only validation.

isdigit is better (see https://github.com/django/django/pull/12679/files#diff-0eb6c5000a61126731553169fddb306eR174 ) int is slow and also will take -443 to be valid ;)

Oh, I forgot about that one, let me push a fix for this.

Mhm, this is tricky. I am not exactly sure on which level to insert isdigit :( I am leaning towards doing it in get_host & get_port since get_raw_uri should not validate it. I also just realized that the host returned from _parsed_host_header is never used, only the port & reconstructed one -- so I am wondering if I can get away by just returning reconstructed scratches head.

I thought you wanted to keep _get_raw_host

Nope not really. All I wanted was to have one function while keeping the behaviour mostly as is and without code duplication.

this changes the semantics of the test, though the test name makes me think it's not actually testing the intended behavior... cookies are not distinguished by port number (https://tools.ietf.org/html/rfc6265#section-8.5) so I would expect this test to have a request with a different port number than the Referer

Good question, adding :4443 might change semantics -- I'll have to double check (though the actual code in the csrf handling might be faulty in that regard). What I am rather sure though is that the removal of SERVER_PORT two lines below is correct either way since the Host header would override it in any case. So if the tests required that before, they had been wrong :)

I think my changes to this test are correct. The function calling it looks like this:
https://github.com/django/django/blob/9fbac5064df4eb5902c48ec3760c282da6d844f4/tests/csrf_tests/tests.py#L659-L665

Ie the cookie domain is set to .example.com and we check if the request is allowed, even though the site is hosted on port 4443 -- effectively checking that the port doesn't matter.

since this is now a reconstructed host header, it will be different from the provided host header e.g. in the case the host header has a default port included: Host: example.com:443 this will now be example.com

I don't think so, my reconstruction keeps the port if what was specified explictly:
See https://github.com/django/django/blob/9fbac5064df4eb5902c48ec3760c282da6d844f4/django/http/request.py#L112 for retrieving the host/port and https://github.com/django/django/blob/9fbac5064df4eb5902c48ec3760c282da6d844f4/django/http/request.py#L125 for reconstructing it. Or do I miss something?

to match the behavior of _get_raw_host() I think this reconstruction should only occur in the SERVER_NAME scenario.

I don't think so, _get_raw_host returned the Host-header as is: https://github.com/django/django/blob/master/django/http/request.py#L110

So if _get_raw_host passed in a port it would have been returned again. This is one of the reasons why the patch looks rather tricky.

namedtuples are weird (indexing syntax) and slow to create (it uses eval internally). Can you make a vanilla class, or use dataclasses (not sure if django 3.2 will use python 3.7+ though)?