Open IGx89 opened 6 years ago
While the behavior change is not a defect, but a difference in behavior on the underlying runtime, the fact that your explicitly set content type is not honored does seem like an issue that needs to be addressed.
Marking this as triaged for investigation.
/cc @mhoeger
Hello! Not sure if this is a bug, but wanted to bring it up just in case. Given the following function:
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.