New information has come to light. If you retrieve the header via request.header.HEADERNAME.values.string , you will get the unparsed header, and the json will not get mangled.
This is a bit unwieldy, but it works.
Hi Ashima
Check this article for some suggestions on handling “multi-valued headers”.
In general, a header that contains a comma is interpreted (blindly) by Apigee Edge as a multi-valued header. If you put JSON in a header, Apigee Edge will treat it as a multi-valued header, and retrieving “request.header.myheadername” will not work nicely.
If you can use the suggestions in the above article, great.
If not then I suggest base64-encoding the JSON on the client side before putting it into the header, then base64-decoding it in Apigee Edge after retrieval.
Thanks for the response. We are already using request.header.cookie.values to fetch all the cookies so that’s not an issue for us but the actual issue is with the json in cookie getting malformed. Although the other solution suggested by you seems feasible but in case something can be done at apigee end only that would be a great help.
Yes, I just tested this and I see the incorrect behavior that you reported. Somehow Apigee Edge is mangling the JSON before you have a chance to receive it, when it is passed in a header. what I can suggest:
encode the JSON with base64 or encodeURIComponent() or similar, before passing. Then decode using the converse algorithm on the Apigee edge side, before trying to parse the JSON . This is how JWT are passed in headers; they are base64-encoded.
Rather than using JSON as your data-encoding format, encode it as something simpler. Like a comma-separated list of key/value pairs. E.g.:
In Apigee Edge, you can read the .values variable, and then parse it as described in that prior article.
I’ll raise a bug on the behavior you’re seeing. It seems to me there ought to be some way of getting the original JSON through un-mangled, without double-encoding it. But anyway for now you have a workaround.
