Thanks for your question.
You have observed that it is not possible to send a Cyrillic (or any Unicode value) in an HTTP Header and then handle that header value in an Apigee Edge proxy. That is consistent with my experience.
What you describe is a general characteristic of HTTP, rather than a phenomenon that is specific to Apigee Edge. Most clients and most proxies and most servers expect HTTP Headers to contain ASCII.
The original HTTP specification, IETF RFC2616 (I won't link to it here, because
it's dead), did not say much about Unicode. In the absence of guidance and to preserve interoperability, most implementers of the spec (people who built clients and servers and proxies) just confined themselves to ASCII.
RFC2616 is dead, and has been for some time. It has been superceded as a specification by the output of the HTTPbis group, including RFC7230, which gets much more specific about what values can be placed into an HTTP Header. In particular, section 3.2.6 says that header values should be digits, alphanumeric, and other non-delimiter ASCII text. Basically this is what most of the world has been doing all along, but now it's official.
So, regarding sending Cyrillic text in headers,
DON'T DO THAT. Likewise with Query params.
If you really need to send non-ASCII in those places, then... you can encode it into ASCII Characters. Maybe try url-encoding the UTF-8 form of the Cyrillic text.
There is no limitation on sending Unicode in the message payload. In fact there is a special header in HTTP that is intended to allow the sender of a request or response to indicate the encoding of the payload: Content-Type. If you would like to send JSON that contains unicode, then:
Content-Type: application/json; charset=UTF-8
Also, the Trace UI shows any unicode bytes in a header as ?. This is not a bug! The data is being interpreted as ASCII (correctly), and for most bytes in the unicode ranges, there is no printable ASCII character.
LinkedIn
Twitter
