Allow specyfing the Content-Type headers that should be encoded as Binary/Base64

[andrezimmermann]

Is your feature request related to a problem? Please describe.
I'm using Hoverfly to capture some HTTP interactions, while most API I've recording are JSON, I sometimes stumble into downloading some CSV files that aren't UTF-8, leading to invalid simulations being captured/recorded.

I end up having to manually edit the captured simulation file by hand which takes some time

Describe the solution you'd like
I'd like to be able to set on the HoverflyConfig, a list of the headers should be automatically encoded into the Base64

As example

@HoverflyCapture(
    config = @HoverflyConfig(
        // Force Hoverfly to treat these types as binary, triggering Base64 encoding
        binaryTypes = {"text/plain", "application/xml", "text/csv"} 
    )
)

Describe alternatives you've considered
I tried to running a middleware to edit the response to replace the Content-Type header from application application/x-csv;charset=windows-31j to application/octet-stream the middleware approach doesn't work when capturing since the response data becomes {"response":{"status":0,"body":"","encodedBody":false}, ... }

Additional context

[tommysitu]

it's quite a specific requirement, I wonder if you can programmatically encode the response in java

[andrezimmermann]

On the application level is not possible, hoverfly sits outside the JVM process so I can't grab the HTTP response and edit it, that would be the middleware responsibility, but unfortunately that is a deadend.

I'd gladly have a SimulationPostprocessor that would behave similarly SimulationPreprocessor but sadly the Simulation already would have the "mojibake"d/garbled text in Response.body field.

While seems very specific, not being able to set what should be set as "base64" is quite limiting when working on API that return anything else than UTF-8 since it's "datastore" is a JSON.

Ideally hoverfly would parse the charset on the Content-Type and whenever is set explicitly as "not UTF-8" it would apply the same logic it has for the application/octet-stream

On ideal world that is, sadly not all APIs that I work it even use the charset property at the Content-Type and just output non UTF-8 bytes and just have a footer in the documentation as "Use Shift-JIS". Or in the case of these CSV downloads, they might just return "text/csv" without specifying any hint of the encoding.

Being able to specify the "binaryTypes" would be a simple compromise, my understanding when implementing this feature is that the go hoverfly application would allow setting this configuration key, defaulting to the current behavior (application/octet-stream) and then also exposing into the Java wrapper. 😄

What you think? 🤔

I really enjoy that Hoverfly uses a single file to store all the captured requests and I can use to replay it later, I've did some work to make sure I have a single simulation file for each Junit @Test it runs and very happy with it, just reaching out to see if we can clear this issue.