Describe the bug

Using the quarkus-azure-functions-http extension it is possible that the http request body can be corrupted by using the wrong charset. This problem does not seem to appear when using the function in Azure on a consumption plan (Y1) but rather when using a premium plan (e.g. P1v3), both Linux.
We are not sure how consistent this can be reproduced but we have been observing this every time now when we switched between the two plans for troubleshooting.

The problem seems to originate from the fact that Azure (for whatever reason) uses a string for the payload instead of a byte[]. This is "fixed" by Quarkus by calling getBytes on it which uses the default charset.

The problem now is that if the payload was e.g. a json in utf-8 before, the payload now could be in e.g windows-1252 which results in the corrupted body in JAX-RS resources.

I am not sure what the correct solution is. If Microsoft could provide a byte[] directly, there would not be any problem in the first place. The correct charset as far as I understand, would be to always use utf-8, because the java worker internally gets the request via a grpc string, which uses Protobuf, where strings are always valid in utf-8 (if I researched and understood everything correctly).

Expected behavior

The payload of a http request is read correctly, regardless on which AppServicePlan the Quarkus function is executed.

Actual behavior

The payload is corrupted which results in e.g. Ä, Ü and Ö being replaced by ?, depending on which AppServicePlan the Quarkus function is executed.

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

17

Quarkus version or git rev

3.4.3

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39)

Additional information

No response