New HTTPRequest.headers not usable in templates because of hyphens

[Mark Tranchant]

With the release of 2.2, I took the opportunity from the new ​HTTPRequest.headers object to clean up old code using e.g. request.META['HTTP_X_REAL_IP'] to request.headers['X-Real-IP'].

However, this new approach does not work with templates, as ​variable lookups cannot use hyphens.

Could the object contain a parallel set of keys in underscored variables? e.g. request.headers['foo-bar'] is also available in request.headers['foo_bar'] and can be looked up with {{ request.headers.foo_bar }} in a template?

[Mark Tranchant]

Patch added.

[Carlton Gibson]

Hi Mark.

The default answer for the template later is to implement a filter that will let you do the lookup with a string. (​StackOverflow has lots of examples.)

Maybe we could allow this by adding a key.replace('_', '-') implementing HttpHeaders.__getitem__()? (Probably worth seeing what a patch there looks like anyway.)

(This instead of storing the items twice in the underlying store.)

[Mark Tranchant]

New patch using getitem()

[Mark Tranchant]

Replying to Carlton Gibson:

Hi Mark.

The default answer for the template later is to implement a filter that will let you do the lookup with a string. (​StackOverflow has lots of examples.)

Maybe we could allow this by adding a key.replace('_', '-') implementing HttpHeaders.__getitem__()? (Probably worth seeing what a patch there looks like anyway.)

(This instead of storing the items twice in the underlying store.)

Yes, I found the filter solution. Whilst that's fine for fixing up user-generated problems, this new problem comes out-of-the-box in 2.2. It feels like there should be a solution along with it.

Your suggestion is much better than mine. New patch added that allows request.headers['foo-bar'] to be looked up in templates as {{ request.headers.foo_bar }} without inelegant double storage.

[Mariusz Felisiak]

Thanks Mark! Are you able to send PR via GitHub?

[Mariusz Felisiak]

​PR

[Mark Tranchant]

Pull request now includes refactoring with Carlton's simplification (thanks!), a simple test, and some documentation.

Whilst I understand the "use a filter instead" argument, and agree with that where the user chooses to supply hyphenated variable names in the context, I believe that as this is a new problem caused by Django itself, it should include a solution that is as neat as other variable lookups. In my case, I tried to use the seemingly-neater replacement for the clunky request.META but ran into this problem.

[Carlton Gibson <carlton.gibson@…>]

In a3a4f5c:

Fixed #30310 -- Added support for looking up HttpHeaders.headers using underscores.