Issue with AsyncClient ignoring default headers compared to synchronous Client

[설원준(Wonjoon Seol)/Dispatch squad]

Description:

Currently, there is an inconsistency between Django's asynchronous AsyncClient and its synchronous counterpart Client regarding the handling of default headers. While the synchronous Client correctly includes default headers, the asynchronous AsyncClient ignores them. This behavior leads to discrepancies when utilizing fixtures with default headers, causing tests to fail unexpectedly.

Reproduction Steps:

Set up a fixture with default headers for both synchronous and asynchronous clients.
Utilize the fixtures in test cases and observe the behavior.
Notice that the synchronous client includes default headers as expected, while the asynchronous client does not.

Code Snippets:

@pytest.fixture(scope="session")
def jwt_token(token_payload: dict[str, Any]) -> str:
    return jwt.encode({"abc", '"abc"}, key='123', algorithm="HS256")

# this passes HTTP_AUTHORIZATION default header
@pytest.fixture(scope="session")
def sync_client_with_token(jwt_token) -> Generator[Client, None, None]:
    yield Client(HTTP_AUTHORIZATION=f"Bearer {jwt_token}")

# this does not
@pytest.fixture(scope="session")
async def async_client_with_token(jwt_token) -> AsyncIterator[AsyncClient]:
    async_client = AsyncClient(HTTP_AUTHORIZATION=f"Bearer {jwt_token}")
    # async_client.defaults["AUTHORIZATION"] = f"Bearer {jwt_token}"
    yield async_client

AsyncRequestFactory.generic() does not currently check if self.defaults exists and ASGIRequest only check hard-coded header names in init() method, effectively ignoring rest of the self.scope values.

Note that while RequestFactory.generic() method does not check whether self.defaults exist but WSGIRequest receives default values via ._base_environ() method when creating WSGIRequest instance.

Proposed Solutions:

Fix Method 1: Modify AsyncRequestFactory.generic() method

class AsyncRequestFactory(RequestFactory):
    def generic(
        self,
        method,
        path,
        data="",
        content_type="application/octet-stream",
        secure=False,
        *,
        headers=None,
        **extra,
    ):
        """Construct an arbitrary HTTP request."""
        parsed = urlparse(str(path))  # path can be lazy.
        data = force_bytes(data, settings.DEFAULT_CHARSET)
        s = {
            "method": method,
            "path": self._get_path(parsed),
            "server": ("127.0.0.1", "443" if secure else "80"),
            "scheme": "https" if secure else "http",
            "headers": [(b"host", b"testserver")],
        }
        if self.defaults: # <- added
            extra = {**self.defaults, **extra} <- added
        if data:
            s["headers"].extend(
                [
                    (b"content-length", str(len(data)).encode("ascii")),
                    (b"content-type", content_type.encode("ascii")),
                ]
            )
            s["_body_file"] = FakePayload(data)
...

Fix Method 2: Modify ASGIRequest
Alternatively, the ASGIRequest class can be adjusted to include default headers in the META attribute during initialisation.

class ASGIRequest(HttpRequest):

    def __init__(self, scope, body_file):
        self.scope = scope
...
        if isinstance(query_string, bytes):
            query_string = query_string.decode()
        self.META = {
            **self.scope, <- # Added
            "REQUEST_METHOD": self.method,
            "QUERY_STRING": query_string,
            "SCRIPT_NAME": self.script_name,
            "PATH_INFO": self.path_info,

This would be simliar to WSGIRequest, where self.META = environ is set during the init phase.
However, it's worth noting that WSGI has a different META format.

asgi META

{'asgi': {'version': '3.0'}, 'type': 'http', 'http_version': '1.1', 'client': ['127.0.0.1', 0], 'server': ('127.0.0.1', '80'), 'scheme': 'http', 'method': 'GET', 'headers': [(b'host', b'testserver'), (b'cookie', b'')], 'HTTP_AUTHORIZATION': 'Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3MTQ0NDg2NzcsImV4cCI6MTcxNDQ1MjI3Nywic3ViX2lkIjoiMSIsInBsYXRmb3JtIjoiVk1TLXN0YWdpbmciLCJiYXNlX3VybCI6Imh0dHBzOi8vc3RhZ2luZy1jZW8tcG9ydGFsLWFwaS55b2dpeW8uY28ua3IvIiwicm9sZSI6InN0YWZmIiwidXNlcl9pZCI6IjEiLCJzdGFmZl9ncm91cF9pZCI6bnVsbH0.WWubd4iOUnsqbWO0ba-8mAsCCk3QDbBONvB_nznZQsk', 'path': '/campaign/v1/campaigns/1/items/', 'query_string': 'date_type=created_at&date_from=2024-04-28+03%3A44%3A37.484747%2B00%3A00&date_to=2024-05-02+03%3A44%3A37.484759%2B00%3A00', 'REQUEST_METHOD': 'GET', 'QUERY_STRING': 'date_type=created_at&date_from=2024-04-28+03%3A44%3A37.484747%2B00%3A00&date_to=2024-05-02+03%3A44%3A37.484759%2B00%3A00', 'SCRIPT_NAME': '', 'PATH_INFO': '/campaign/v1/campaigns/1/items/', 'wsgi.multithread': True, 'wsgi.multiprocess': True, 'REMOTE_ADDR': '127.0.0.1', 'REMOTE_HOST': '127.0.0.1', 'REMOTE_PORT': 0, 'SERVER_NAME': '127.0.0.1', 'SERVER_PORT': '80', 'HTTP_HOST': 'testserver', 'HTTP_COOKIE': ''}

ASGI META has separate 'headers' but the custom headers are not added there.

wsgi META

{'HTTP_COOKIE': '', 'PATH_INFO': '/campaign/v1/campaigns/1/items/', 'REMOTE_ADDR': '127.0.0.1', 'REQUEST_METHOD': 'GET', 'SCRIPT_NAME': '', 'SERVER_NAME': 'testserver', 'SERVER_PORT': '80', 'SERVER_PROTOCOL': 'HTTP/1.1', 'wsgi.version': (1, 0), 'wsgi.url_scheme': 'http', 'wsgi.input': <django.test.client.FakePayload object at 0x1061b0d90>, 'wsgi.errors': <_io.BytesIO object at 0x104f42020>, 'wsgi.multiprocess': True, 'wsgi.multithread': False, 'wsgi.run_once': False, 'HTTP_AUTHORIZATION': 'Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3MTQ0NDg3OTQsImV4cCI6MTcxNDQ1MjM5NCwic3ViX2lkIjoiMSIsInBsYXRmb3JtIjoiVk1TLXN0YWdpbmciLCJiYXNlX3VybCI6Imh0dHBzOi8vc3RhZ2luZy1jZW8tcG9ydGFsLWFwaS55b2dpeW8uY28ua3IvIiwicm9sZSI6InN0YWZmIiwidXNlcl9pZCI6IjEiLCJzdGFmZl9ncm91cF9pZCI6bnVsbH0.MkbgS1zDaMLdDMLC0_Jpe_2O7VBtJD8km70Y0KlUb4g', 'QUERY_STRING': 'date_type=created_at&date_from=2024-04-28+03%3A46%3A35.172175%2B00%3A00&date_to=2024-05-02+03%3A46%3A35.172190%2B00%3A00'}

Addressing this inconsistency will ensure that the behaviour of both synchronous and asynchronous clients remains consistent and predictable across Django applications.

Thanks.