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

[Troon]

Added getitem() to HttpHeaders.headers to include underscore-to-hyphen lookup for use in templates.

[felixxm]

@Troon Thanks for this patch 👍 Tests are required.

[carltongibson]

Could this not just be a one-liner:

def __getitem__(self, key):
    return super().__getitem__(key.replace('_', '-'))

?

[ngnpope]

I'm not sure about this. It is adding something to django.http.request that is a workaround for something you are trying to do in a template.

You can solve this in your project by adding a template filter for dictionary lookups: {{ headers|lookup:'foo-bar' }}. There are plenty of examples of how to implement such a filter that you can search for.

(In addition to tests this would also need a Trac ticket.)

[Troon]

Could this not just be a one-liner:

def __getitem__(self, key):
    return super().__getitem__(key.replace('_', '-'))

?

No: it needs to work for published new behaviour ("user-agent") and in templates ("user_agent").

I'm trying to figure out how to update the branch, as I now have this:

    def __getitem__(self, key):                                                 
        """                                                                     
        Django template variables cannot contain hyphens, so to allow use       
        of the headers object in templates, we also try to look up the          
        variable with underscores. For example, use headers['foo-bar']          
        in views, and {{ headers.foo_bar }} in templates.                       
        """                                                                     
        try:                                                                    
            return super().__getitem__(key)                                     
        except KeyError:                                                        
            return super().__getitem__(key.replace('_', '-'))                   

[carltongibson]

>>> "user-agent".replace('_', '-')       
'user-agent'

[ngnpope]

No: it needs to work for published new behaviour ("user-agent") and in templates ("user_agent").

Actually @carltongibson is correct. The header values are always hyphenated, so always converting underscores to hyphens will allow both strings to work.

[Troon]

>>> "user-agent".replace('_', '-')       
'user-agent'

Heh, of course. Sorry.

[carltongibson]

So Nick's point is the one I raised on the ticket: the standard approach here is to implement just such a filter. (Or to do it in get_context_data() in the view...)

So here's the question for reviewers: as an affordance here, is this an addition we'd like to add? ("No, wontfix", is an allowed answer there.)

[carltongibson]

Avoid use of "we". (See Coding Style guidelines 👍)

[ngnpope]

I'll defer to @carltongibson and @felixxm on this. It is a trivial two line addition.

[rixx]

I'd like to see this change in Django (once tests have been provided, of course). Saying "here is a new easy way to interface with headers!" and then having it be hard to use in templates defeats the purpose for at least a large subset of Django users, and this change alleviates the problem at basically no cost.

[carltongibson]

Hi @pope1ni, @felixxm. I'm inclined to accept this, make a the couple of cosmetic changes and pull it in. (I've ummed and arghed about but in the end think pragmatism beats purity here.) If you don't object I'll proceed, otherwise we can widen the discussion to the list and see what people think? (I'm very happy with either, so if you do hate it shout now. 🙂)

[ngnpope]

Hi @carltongibson. Fine by me - thinking on this some more, it feels generally useful. There's still an outstanding comment regarding simplifying the docstring and a missing release note.

As this is a straightforward two line addition I wouldn't be adverse to it being backed to 2.2 where request.headers was introduced, if only to prevent reports of this issue recurring in the months ahead until 3.0 arrives. But I guess that's up to you and @felixxm to decide!

[carltongibson]

Hey Nick. Thanks for the quick reply.

I'm not sure about back porting... In the strictest of worlds it doesn't really qualify. (It's a new feature on a new feature, rather than a bug on a new feature...)

[ngnpope]

In the strictest of worlds it doesn't really qualify.

Agreed. Was just putting it out there that this one might come back to be annoying...

[carltongibson]

Hey @Troon. Thanks for the contribution! Good job! Welcome aboard! 🎉