You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Consider having received headers be bytes, not unicode strings. #154
Currently the RequestReceived, ResponseReceived, and TrailersReceived events all return the headers as a list of tuples of unicode strings. This happens because HPACK decodes the headers as UTF-8 before use. While this is enormously convenient when it works, which is almost all the time, it introduces the risk that a senseless HTTP/2 implementation may send non-UTF-8-encoded data and have hyper-h2 barf on it.
For the 2.x series we're stuck with this design decision, but when we come to look at doing a 3.0.0 we may want to revisit this decision.
I think this is fully covered in #198 - and the only remaining thing to discuss/decide is to change the default encoding from utf-8 to no encoding in a 3.0 release.
Personally I have no strong opinion, since changing it is a simple flag on the connection. However I'm slightly leaning toward going raw bytes-only for all internals, just so API users need to think about what they expect to get and what they actually want.
Agreed, this issue is basically whether or not we change the default. I remain +1 on changing the default: I think unicode-by-default was the wrong choice, though it seemed sensible back when I first made that call in 2014.
Activity
Kriechi commentedon Jun 30, 2016
I think this is fully covered in #198 - and the only remaining thing to discuss/decide is to change the default encoding from
utf-8to no encoding in a 3.0 release.Personally I have no strong opinion, since changing it is a simple flag on the connection. However I'm slightly leaning toward going raw bytes-only for all internals, just so API users need to think about what they expect to get and what they actually want.
Lukasa commentedon Jul 1, 2016
Agreed, this issue is basically whether or not we change the default. I remain +1 on changing the default: I think unicode-by-default was the wrong choice, though it seemed sensible back when I first made that call in 2014.