Azure HttpTrigger函数遇Accept-Encoding格式错误返回Bad Request的解决问询

部署在Azure上的Azure Function，当请求头Accept-Encoding的值为gzip deflate时返回Bad Request响应，但本地运行正常。已知该请求头的正确格式应为gzip, deflate（用逗号分隔），想知道是否可以替换该请求头值为正确格式，或者覆盖Azure基础设施返回Bad Request的行为？

已尝试使用自定义中间件workerApplication.UseMiddleware<MyCustomMiddleware>()，但未解决问题。

代码示例 #

public class Function1
{
    [Function("Function1")]
    public IActionResult Run([HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req)
    {
        return new OkObjectResult("Welcome to Azure Functions!");
    }
}

请求示例 #

curl --location 'https://<website>.azurewebsites.net/api/Function1?code=7tv0BEWCJdpBmAqjKObYUl6VXtTJWsyUmOY3TjdmhP7nAzFu-o0avw%3D%3D' \
--header 'Accept-Encoding: gzip deflate'

响应示例 #

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML>

<HEAD>
    <TITLE>Bad Request</TITLE>
    <META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii">
</HEAD>

<BODY>
    <h2>Bad Request</h2>
    <hr>
    <p>HTTP Error 400. The request is badly formed.</p>
</BODY>

</HTML>

解决方案与见解 #

自定义中间件无效原因 #

这个400错误是由Azure前端基础设施（如App Service的IIS层）返回的，请求还没到达你的Function代码或自定义中间件就被拦截，所以中间件无法处理这类请求。

可行解决途径 #

• 修正请求源格式
  最直接的方式是让发起请求的客户端将Accept-Encoding的值改为标准格式gzip, deflate，从根源避免不符合规范的请求。

• 添加前置代理服务
  如果无法修改客户端请求，可以在Azure Function前部署Azure Front Door或API Management，在这些服务中配置请求头转换规则，将Accept-Encoding: gzip deflate替换为Accept-Encoding: gzip, deflate后再转发到Function，让请求在到达Function前完成修正。

• 调整应用服务设置
  尝试添加以下应用设置，调整IIS的请求验证行为（需测试对其他功能的影响）：

  • 设置WEBSITE_DISABLE_FIRST_CLASS_APIS为true：禁用部分App Service内置API验证规则
  • 设置HTTP_ERROR_PASSTHROUGH为true：尝试让错误直接传递到Function代码处理

关键说明 #

Azure基础设施层对HTTP规范的校验严格，不符合RFC标准的请求头（如用空格代替逗号分隔编码格式）会被直接拦截返回400，这种场景下Function代码本身无法处理，必须在请求到达Function之前完成修正或跳过校验。

内容的提问来源于stack exchange，提问作者Siri