重试请求以“内容长度不匹配”结尾答案

【问题标题】：Retry request ends with "Content length mismatch"重试请求以“内容长度不匹配”结尾
【发布时间】：2020-08-05 12:54:53
【问题描述】：

我的问题是这样的：

我有一个 Azure APIM，我创建了一个 API 并添加了后端重试策略，如下所示。

<backend>
    <retry condition="@("{{Transient-ErrorCode}}".Contains(Convert.ToString(context.Response.StatusCode)))" count="3" interval="5" first-fast-retry="false">
        <forward-request />
    </retry>
</backend>

服务器第一次返回成功（状态码：200），当它启动重试时遇到以下情况（我也在重试成功，测试重试工作正常。）。

forward-request (1.326 ms)
{
"messages": [
    "Content length mismatch",
    "Content length mismatch"
    ]
}

请帮助您的想法/经验。

【问题讨论】：

标签： azure azure-api-management retrypolicy

【解决方案1】：

这是因为客户端发送的请求在 APIM 中默认不会缓存在内存中，而是直接从客户端流式传输到后端。因此，当需要重试请求时，请求有效负载不存在。我假设您只对具有正文的请求有问题。

要解决此问题，您首先需要缓存请求正文：

<inbound>
    <set-variable name="body" value="@(context.Request.Body.As<string>(preserveContent: true))" />
</inbound>
<backend>
    <retry condition="@("{{Transient-ErrorCode}}".Contains(Convert.ToString(context.Response.StatusCode)))" count="3" interval="5" first-fast-retry="false">
        <set-body>@((string)context.Variables["body"])</set-body>
        <forward-request />
    </retry>
</backend>

【讨论】：

检查请求是否有正文的最佳方法是什么？用例将用于全局策略。
我检查了正文是否为空，然后将变量设置为空字符串...但我不确定副作用。
context.Request.HasBody

【解决方案2】：

在forward-request 策略中使用属性buffer-request-body 似乎有另一种简化方法：

<!-- no need to put body into variable in the inbound policy -->
<backend>
    <retry condition="@("{{Transient-ErrorCode}}".Contains(Convert.ToString(context.Response.StatusCode)))" count="3" interval="5" first-fast-retry="false">
        <!-- no need for the set-body policy -->
        <forward-request buffer-request-body="true" />
    </retry>
</backend>

见doco for forward-request's attributes

【讨论】：

就是这样