Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Azure Functions Http: corrupted request body #36973

Closed
Nithanim-Work opened this issue Nov 9, 2023 · 4 comments · Fixed by #40673
Closed

Azure Functions Http: corrupted request body #36973

Nithanim-Work opened this issue Nov 9, 2023 · 4 comments · Fixed by #40673
Labels
area/azure-functions env/windows Impacts Windows machines kind/bug Something isn't working
Milestone

Comments

@Nithanim-Work
Copy link

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

@Nithanim-Work Nithanim-Work added the kind/bug Something isn't working label Nov 9, 2023
@quarkus-bot quarkus-bot bot added env/windows Impacts Windows machines triage/needs-triage labels Nov 9, 2023
@gsmet
Copy link
Member

gsmet commented Nov 10, 2023

/cc @patriot1burke

@patriot1burke
Copy link
Contributor

Worker never supported byte[] before. Is it possible for you to try rebuilding quarkus and just change the getBytes to getBytes(UTF_8)? I don't have access to the premium plan.

@Nithanim-Work
Copy link
Author

For a more easily testable workaround for us, I copied the extension from the quarkus source to its own separate extension: https://github.com/Nithanim-Work/quarkus-issues-36973 (Line)

This now works in both the Y1 and P1v3 AppServicePlan.

The problem should also occur if you run a quarkus azure http function locally on windows (or with forced different default charset for the jvm) with the full function worker execution dance-around locally. But I have not tested that yet.

@Nithanim-Work
Copy link
Author

I finally found time to allow building and running a custom Quarkus version. We are currently using this commit successfully: Nithanim-Work@1f94399 on branch https://github.com/Nithanim-Work/quarkus/tree/issue-36973-3.4.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/azure-functions env/windows Impacts Windows machines kind/bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants