Open xlq20080808 opened 10 months ago
Base64 encoding and decoding of non-ASCII code attachment can solve this problem
Because the header of HTTP2 does not support non-ASCII code.
Because the header of HTTP2 does not support non-ASCII code.
This is the case, which will cause the attachment to different behavior under the dubbo and triple protocols. Is it necessary for us to support it? I tried to use base64 encode to achieve it #12905
Environment
Steps to reproduce this issue
reproduce this issue.
Expected Behavior
Consistent with the attachment of the dubbo protocol, The triple protocol can also pass values containing non-ASCII characters
Actual Behavior
Non-ASCII characters are converted to '?'
Problem Code
The netty's huffman encoding condition
Not hit netty's huffman encoding condition
When netty does not hit the huffman encoding of the header, it will convert the non-ascii code to '?'
Hit netty's huffman encoding condition
4.1.86.Final Netty has a bug in the conversion
When netty hits the huffman encoding condition of the header, non-ASCII characters are cleaned to the ASCII range
Such a convert may cause unexpected errors Non-ASCII characters may be converted to characters less than 32 For example, envoy will check the value of the header, and if it finds characters less than 32, it will report an error