Opened 4 years ago

Closed 3 months ago

#16068 closed New feature (duplicate)

Ease access to request headers

Reported by: jgorset Owned by: jgorset
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 4 years ago by d0ugal

  • Easy pickings unset
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

comment:2 Changed 4 years ago by jgorset

  • Owner changed from nobody to jgorset
  • Status changed from new to assigned

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 4 years ago by lukeplant

  • Triage Stage changed from Design decision needed to Accepted

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 4 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:5 Changed 3 months ago by timgraham

  • Resolution set to duplicate
  • Status changed from assigned to closed

Duplicate of #20147 which has more discussion.

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