In our case, it adds 2.3s to a build that takes way longer than that. (Our build creates Foundation namespaces, and loading the FHIR resources takes insanely long.) I expect this to be Python startup time, plus some time proportional to the amount of data to copy (roughly 300MB in my test).

Thanks, this is very useful. I've just tested this on an image with various build steps, and this saves us quite a bit of image space. The copy step now adds a little under 300MB to the base image, instead of almost 5GB (!). Squashing an image has the same effect, but prevents layer caching, so each push to a docker repository would upload the entire image. Your way, after the first time, presumably just the 300MB. Nice!

Interestingly, we've had already contacted our sales engineers about the massive amount of image disk space used after our build steps. I couldn't find what it's used for; the actual Linux filesystem is way smaller. The build steps also don't visibly use significant disk space, that I could find. I'm hoping InterSystems manages to do something about this in the future. In the meantime, we've got a nice workaround. Thanks again!

I would file this with WRC. The settings documentation suggest that you can specify the in- and output encoding with the Charset (Tekenset) setting. That implies that you should set that to utf-8, but that doesn't actually work. From looking at the source code, it appears that the business service (EnsLib.REST.Service) hardcodes a %GlobalBinaryStream response stream, which will output the bytes as they are.

As a workaround you could convert (encode) the stream to UTF-8 yourself before sending it.