Ease access to request headers

[Johannes Gorset]

In the current implementation of the HttpRequest class, one must parse the environment variables passed to Django by WSGI to access the request headers. It would be more pythonic if accessing HttpRequest headers conformed to accessing HttpResponse headers.

    
    # Current implementation
    user_agent = request.META['HTTP_USER_AGENT']
    cache_control = response['Cache-Control']
    
    # Proposed implementation
    user_agent = request['User-Agent']
    cache_control = response['Cache-Control']
    

[Johannes Gorset]

This ought to be an easy design decision to make. It's pretty crude to parse environment variables for the request headers, and I'd be happy to alleviate it.

[Luke Plant]

On first look, this seems like an obvious and good enhancement. People using Django should be insulated from the rather strange way that CGI/WSGI mutilate header names.

There are a few issues, however, for a patch to be accepted.

1. Firstly - we really want 'one way to do it', for the sake of consistency, and especially to make it easy to grep source code for headers. But we already have a documented way of doing this - using META. Lots of code and tests already assume this, and django.test.client.Client and RequestFactory accept keywords parameters for updating the base environment using WSGI conventions - so you pass things like 'HTTP_REFERER'. It would suck if we had to remember that test code used WSGI names to set headers, but view code used HTTP names. Given that HTTP names are often not valid keyword argument names, we may need an additional 'headers' keyword argument to RequestFactory.

2. We also need to think about how exactly we do the conversion, and issues of case sensitivity - HTTP headers are case insensitive.

3. We need to think about at what point we do the conversion, and any overhead associated with that. Currently we have no overhead associated with headers, since we just use the environment dictionary passed from mod_wsgi (I think).`

I think these issues together mean that __getitem__ and __setitem__ will strictly be wrappers around request.META. But note that Content-Type and Content-Length are handled differently, and don't get the 'HTTP_' prefix.

So, I'm going to accept. But this is actually quite a lot of work - we want a patch that will leave our code base with a single way to examine headers in requests, and set request headers in test code, with compatibility with the old way. (We might make exceptions for the implementation of RequestFactory, but for our own use of RequestFactory and other people's use of it, there should be One Way to spell HTTP headers).

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Tim Graham]

Duplicate of #20147 which has more discussion.