Opened 6 years ago

Closed 2 years ago

#16068 closed New feature (duplicate)

Ease access to request headers

Reported by: Johannes Gorset Owned by: Johannes Gorset
Component: HTTP handling Version: 1.3
Severity: Normal Keywords: headers
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


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']

Change History (5)

comment:1 Changed 6 years ago by Dougal Matthews

Easy pickings: unset
Triage Stage: UnreviewedDesign decision needed

comment:2 Changed 6 years ago by Johannes Gorset

Owner: changed from nobody to Johannes Gorset
Status: newassigned

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.

comment:3 Changed 6 years ago by Luke Plant

Triage Stage: Design decision neededAccepted

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.
  1. We also need to think about how exactly we do the conversion, and issues of case sensitivity - HTTP headers are case insensitive.
  1. 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).

comment:4 Changed 5 years ago by Aymeric Augustin

UI/UX: unset

Change UI/UX from NULL to False.

comment:5 Changed 2 years ago by Tim Graham

Resolution: duplicate
Status: assignedclosed

Duplicate of #20147 which has more discussion.

Note: See TracTickets for help on using tickets.
Back to Top