Currently I’m making a calling HTTP service as a client and data was corrupted when covert byte to string in webmethod 10.15.
For some reason, when I get a 200 response from Host, there’s no any problem.(well converted), data corruption have only with 400 response.(in postman, response is well converted.)
Please check is there any problems or not.

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/11c514ed45cb186c62f6e195968767dd6a7ec9eb_2_1035x330.png 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/11c514ed45cb186c62f6e195968767dd6a7ec9eb_2_1380x440.png 2x" data-dominant-color="F5F7F5">

image1862×594 118 KB

Hi,

looks like there is a missing map step between the invocations of pub.client:http and byteToString.
Please add the proper screen shots.

Regards,
Holger

Try without passing encoding in both http step and bytesToString steps

I tried like a below, but still fail to convert when get 400 error

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/98d8edfb5fb012f2b92f0121431f535f791c5f0d_2_489x750.png 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/98d8edfb5fb012f2b92f0121431f535f791c5f0d_2_652x1000.png 2x" data-dominant-color="F8F8F8">

image1252×1916 189 KB

Try these options

1. If Target API has swagger file, then create REST API descriptor (RAD consumer) and test using connectors if it is giving same response for 400 vs 200/404.

2. Compare response headers coming to postman when request is 400 vs 404 /200, check if there are any differences in content-type or encoding.

My guess is the response is gzip’d (or compressed with other Content-Encoding directive). Clients like Postman will automatically decompress such responses without you needing to do anything explicit.

You can check this by viewing the headers that are returned. If you share a screen shot of variables returned in the header output, we can confirm that is what is happening.

In the request you can send the Accept-Encoding: identity to tell the server to not encode the response. But this is not always honored. We had a case where an API always compressed regardless of what we sent in Accept-Encoding. And did so only for error responses whereas 2xx responses were always clear text.

You can create your own general purpose http service that adds capability such as this to the built-in pub.client:http .

The steps are not checking the HTTP response – but should.

Side note: I have never seen a case where the claim is “data is corrupted” that the data is actually corrupted. Invariably, it is due to incorrect character endoding (e.g. using ASCII for parsing UTF-8 byte) or to compression. The rule of thumb is if you see binary data when you expect to see text, the most likely culprit is incorrect assumptions/information about what the byte stream represents.