Azure / Azure/azure-functions-host
UTF-16 differences between v1 and v2 runtimes
- Dominant language
- C#
- Stars
- 2k
- Forks
- 482
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 38
Description
Hello! Not sure if this is a bug, but wanted to bring it up just in case. Given the following function:
```
module.exports = function (context, req) {
context.res = {
body: { 'message': 'success'},
headers: {
'Content-Type': 'application/json; charset=utf-8',
}
};
context.done();
};
```
making a request to it with an "Accept-Charset: us-ascii, utf-16, utf-8" header returns a response with a Content-Type charset of "utf-8" under the v1 runtime and "utf-16" under the v2 runtime.
There are two things noteworthy about that: v2's behavior is different than v1's, and v2 is not respecting the charset I explicitly set.
Again, this may be completely intentional, but wanted to confirm just in case it wasn't. This came up because I have a client saying it supports utf-16 when it doesn't (Google Dialogflow :p ) and the only way I've been able to address that issue (besides by going back to the v1 runtime) is by putting my function behind API Management and using an inbound policy rule to strip out its Accept-Charset header.
Contributor guide
Research direction
Start by reproducing the provided function under the v1 and v2 runtimes with the stated Accept-Charset header, then inspect the host's HTTP response handling. Done means determining the intended charset behavior and documenting or correcting the v2 response so it respects the explicit Content-Type setting consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, csharp
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100