cty/json: configure (non-)HTML-escaping serialization about go-cty HOT 3 CLOSED

Hi @johakoch! Thanks for sharing this feature request.

While I can see that this extra escaping is a cosmetic irritant, it's still a valid serialization of the input data and so I feel disinclined to cause potential churn by changing the default behavior, or to complicate the API by making it configurable.

Can you say more about why it matters for your use-case exactly how the JSON data is encoded, assuming that it always generates valid JSON? When I wrote this I did it on the assumption that JSON encoded cty objects are primarily for machine consumption and so human readability was not a priority. That is also why it always generates minified JSON, for example, with no option to configure that either.

from go-cty.

Hi @apparentlymart .
For Couper we use hcl as our configuration language which also allows to compose some individual payloads via variables either as part of a response or request json_body. This is enabled with converting the related payload to cty and vice versa (hcl evaluation). At this point the user does not expect a modification of its content which happens due to the json.Marshal default behaviour.

A simple example which has been solved in our fork:

# simple server endpoint which reflects the client json payload
server {
  endpoint "/json" {
      response {
        json_body = request.json_body
      }
  }
}

curl -X POST -H "Content-Type: application/json" -d '{ "prop": "<p>html</p>" }' http://localhost:8080/json

{"prop":"\u003cp\u003ehtml\u003c/p\u003e"}

An additional use-case would be the proxy case which connects a (legacy?) system which may also send unescaped data and we want to read/sniff into them for whatever reasons which may prevent us to pipe the body.

So it may solve just our use-case but we could think about a better integration of an possible opt out for html escaping if you give us a thump up ;)

from go-cty.