Api 管理层为单向请求设置转发请求
Api Management sets forward-request for a one way request
我想记录请求和响应,所以我在入站和出站部分放置了一个单向请求:
<policies>
<inbound>
<send-one-way-request mode="new">
<set-url>@("example.com")</set-url>
<set-method>POST</set-method>
<set-header name="Content-Type" exists-action="override">
<value>application/json</value>
</set-header>
<set-body>@(context.Request.Body.As<string>(preserveContent: true))</set-body>
</send-one-way-request>
</inbound>
<backend>
<base />
</backend>
<outbound>
<send-one-way-request mode="new">
<set-url>@("example.com")</set-url>
<set-method>POST</set-method>
<set-header name="Content-Type" exists-action="override">
<value>application/json</value>
</set-header>
<set-body>@(context.Response.Body.As<string>(preserveContent: true))</set-body>
</send-one-way-request>
</outbound>
</policies>
相同的调用,除了正文。
当我检查跟踪时,我在入站部分看到了这个:
发送单向请求(0 毫秒)
"One way request was successfully send to https://...."
转发请求(9690 毫秒)
{
"response": {
"status": {
"code": 200,
"reason": "OK"
},
"headers": [
{
"name": "Pragma",
"value": "no-cache"
},
{
"name": "Content-Length",
"value": "2"
},
{
"name": "Cache-Control",
"value": "no-cache"
},
{
"name": "Content-Type",
"value": "application/json; charset=utf-8"
},
{
"name": "Date",
"value": "Wed, 05 Jul 2017 07:56:14 GMT"
},
{
"name": "Expires",
"value": "-1"
},
{
"name": "Server",
"value": "Microsoft-IIS/8.0"
},
{
"name": "X-AspNet-Version",
"value": "4.0.30319"
},
{
"name": "X-Powered-By",
"value": "ASP.NET"
}
]
}
}
但在出境中我只得到:
发送单向请求(0 毫秒)
"One way request was successfully send to https://...."
并且没有转发请求。因为我使用单向请求,所以我不希望调用有响应,而且我不记得在入站部分有 forward-request
(在保存的单向调用中没有找到它们入站请求)。
是否有任何其他配置可以触发转发请求?
编辑:
我使用 azure 函数来处理这个问题。当我在子域中输入错误时,转发请求消失了,但是当我在函数名称中输入错误时,它仍然存在...两个请求都指向同一个 azure 函数。
编辑2:
这变得更加混乱:当我从 swagger 文件发送默认正文时,请求转发不存在。如果我重复请求或修改默认正文,它会出现...
由于单向发送请求策略在请求处理本身方面是完全异步的,因此无法保证来自此类请求的回复会被记录下来,因为在收到回复时,请求本身可能已被长时间处理,响应连同跟踪信息一起返回给客户端。因此它会尽力而为,如果在收到对发送单向请求的响应时主请求仍在处理中,则响应将被记录,否则不会。
在第一个示例中,对入站单向请求的回复被记录下来,因为在主请求上还有很多处理要做——将请求发送到后端,处理出站部分。但是,当单向请求作为出站中的最后一条语句放置时,就在发送对客户端的响应之前 - 对单向请求的响应来得太晚,无法进行跟踪。
子域中的拼写错误可能会导致更长的连接时间,如果该域不主动拒绝连接,则会停止响应,从而从跟踪中消失。
一切都是时间问题。如果您想确保主请求处理停止,直到您收到这些副请求的响应,请改用发送请求策略。
我想记录请求和响应,所以我在入站和出站部分放置了一个单向请求:
<policies>
<inbound>
<send-one-way-request mode="new">
<set-url>@("example.com")</set-url>
<set-method>POST</set-method>
<set-header name="Content-Type" exists-action="override">
<value>application/json</value>
</set-header>
<set-body>@(context.Request.Body.As<string>(preserveContent: true))</set-body>
</send-one-way-request>
</inbound>
<backend>
<base />
</backend>
<outbound>
<send-one-way-request mode="new">
<set-url>@("example.com")</set-url>
<set-method>POST</set-method>
<set-header name="Content-Type" exists-action="override">
<value>application/json</value>
</set-header>
<set-body>@(context.Response.Body.As<string>(preserveContent: true))</set-body>
</send-one-way-request>
</outbound>
</policies>
相同的调用,除了正文。
当我检查跟踪时,我在入站部分看到了这个:
发送单向请求(0 毫秒)
"One way request was successfully send to https://...."
转发请求(9690 毫秒)
{
"response": {
"status": {
"code": 200,
"reason": "OK"
},
"headers": [
{
"name": "Pragma",
"value": "no-cache"
},
{
"name": "Content-Length",
"value": "2"
},
{
"name": "Cache-Control",
"value": "no-cache"
},
{
"name": "Content-Type",
"value": "application/json; charset=utf-8"
},
{
"name": "Date",
"value": "Wed, 05 Jul 2017 07:56:14 GMT"
},
{
"name": "Expires",
"value": "-1"
},
{
"name": "Server",
"value": "Microsoft-IIS/8.0"
},
{
"name": "X-AspNet-Version",
"value": "4.0.30319"
},
{
"name": "X-Powered-By",
"value": "ASP.NET"
}
]
}
}
但在出境中我只得到:
发送单向请求(0 毫秒)
"One way request was successfully send to https://...."
并且没有转发请求。因为我使用单向请求,所以我不希望调用有响应,而且我不记得在入站部分有 forward-request
(在保存的单向调用中没有找到它们入站请求)。
是否有任何其他配置可以触发转发请求?
编辑:
我使用 azure 函数来处理这个问题。当我在子域中输入错误时,转发请求消失了,但是当我在函数名称中输入错误时,它仍然存在...两个请求都指向同一个 azure 函数。
编辑2:
这变得更加混乱:当我从 swagger 文件发送默认正文时,请求转发不存在。如果我重复请求或修改默认正文,它会出现...
由于单向发送请求策略在请求处理本身方面是完全异步的,因此无法保证来自此类请求的回复会被记录下来,因为在收到回复时,请求本身可能已被长时间处理,响应连同跟踪信息一起返回给客户端。因此它会尽力而为,如果在收到对发送单向请求的响应时主请求仍在处理中,则响应将被记录,否则不会。
在第一个示例中,对入站单向请求的回复被记录下来,因为在主请求上还有很多处理要做——将请求发送到后端,处理出站部分。但是,当单向请求作为出站中的最后一条语句放置时,就在发送对客户端的响应之前 - 对单向请求的响应来得太晚,无法进行跟踪。
子域中的拼写错误可能会导致更长的连接时间,如果该域不主动拒绝连接,则会停止响应,从而从跟踪中消失。
一切都是时间问题。如果您想确保主请求处理停止,直到您收到这些副请求的响应,请改用发送请求策略。