Demian Brecht added the comment:

> But it is not natural to do things like this (based on headers sent by 
> Firefox)

Good point.

> Otherwise, retaining the one_value.encode('latin-1') call is confusing when 
> later on it rejects non-ASCII-encoded characters.

I’m a little torn on this one given one of the SHOULD clauses in RFC 7230 about 
recipients treating headers with non-ASCII characters as opaque data. However, 
I’ve read a number of occasions where users are using latin-1 in practice (and 
it /is/ only a SHOULD clause), so I think it’s likely better to err on the side 
of caution and allow for the latin-1 charset at least.

As for utf-8 though, I think that once we start getting into the realm of other 
application protocols, that’s something that should have to be extended by the 
client implementation and not something that should be changed in the base HTTP 
implementation.

The odd part of the API though now is the fact that it’s variadic. I really 
have no strong opinion on whether elements should be tab or space delimited and 
the RFC doesn’t seem to lean either way. I think I’m still leaning towards 
space delimiting to give users the ability to write in either form 
(putheader(‘Authorization’, ‘Bearer’, ‘token’) or putheader(‘Authorization’, 
‘Bearer token’)). As another minor argument for it, it’s also likely a little 
nicer for logging. I think that optimally, the API would be a single value as 
you’d suggested, but I’d be concerned about the extent of backwards 
compatibility issues if that were to be done.

I’ll try to get some time tomorrow to make those changes, so it still leaves 
time for further debate :)

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22928>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to