【APIM】分享APIM策略用于检查请求实体(Request Body Size)大于50MB直接返回提示信息

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
应用实时监控服务-可观测链路OpenTelemetry版,每月50GB免费额度
应用实时监控服务-应用监控,每月50GB免费额度
简介: 在使用APIM服务时,上传大文件可能影响性能。可通过APIM策略监测请求体大小,若超过50MB,则返回413错误。具体实现包括获取Content-Length、使用choose判断大小,并通过return-response返回提示信息。

问题描述

使用APIM服务,当遇见上传文件的请求时,需要考虑大文件对APIM性能的影响。

所以,是否可以使用APIM策略来监测请求body大小,如果超过50MB,就返回413 Payload too Large呢?

 

问题解答

当然可以。实现思路如下:

1:  在API的Policy中,在Inbound中获取请求的Size(context.Request.Headers["Content-Length"][0])并保存为一个参数bodySize

2:  使用choose 语句来判断bodySize小于 50MB ( 50 * 1024 * 1024 = 52428800 bytes), 小于则继续。

3:  如果大于了50MB,就使用 return-response 返回413并添加提示信息

 

示例策略如下:

<policies>
    <inbound>
        <base />
        <set-variable name="bodySize" value="@(context.Request.Headers["Content-Length"][0])" />
        <choose>
            <when condition="@(int.Parse(context.Variables.GetValueOrDefault<string>("bodySize"))<52428800)">
                <!--let it pass through by doing nothing-->
            </when>
            <otherwise>
                <return-response>
                    <set-status code="413" reason="Payload too large" />
                    <set-body>@{
                       return "Maximum allowed size for the requests is 50 MB. This request has size of "+ context.Variables.GetValueOrDefault<string>("bodySize") +" bytes";
                    }</set-body>
                </return-response>
            </otherwise>
        </choose>
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

测试结果如下:

 

参考资料

APIM Policy 设置变量 : https://docs.azure.cn/zh-cn/api-management/set-variable-policy

APIM Policy 返回响应 : https://docs.azure.cn/zh-cn/api-management/return-response-policy

APIM Policy 控制流 : https://docs.azure.cn/zh-cn/api-management/choose-policy

How to prevent large file POST requests using Azure APIM? https://stackoverflow.com/questions/60448273/how-to-prevent-large-file-post-requests-using-azure-apim

 

 


 

当在复杂的环境中面临问题,格物之道需:浊而静之徐清,安以动之徐生。 云中,恰是如此!

相关文章
|
2月前
|
Java API 微服务
为什么虚拟线程将改变Java并发编程?
为什么虚拟线程将改变Java并发编程?
251 83
|
2月前
|
Web App开发 前端开发 JavaScript
前端新利器:CSS容器查询——让组件真正“自适应
前端新利器:CSS容器查询——让组件真正“自适应
250 83
|
2月前
|
安全 编译器 PHP
PHP 8 新特性:现代化开发的飞跃
PHP 8 新特性:现代化开发的飞跃
240 89
|
2月前
|
SQL JSON Java
告别拼接噩梦:Java文本块让多行字符串更优雅
告别拼接噩梦:Java文本块让多行字符串更优雅
367 82
|
2月前
|
Web App开发 前端开发 数据可视化
用 CSS Grid 实现高效布局的 3 个实战技巧
用 CSS Grid 实现高效布局的 3 个实战技巧
|
3月前
|
Python
掌握Python装饰器:轻松统计函数执行时间
掌握Python装饰器:轻松统计函数执行时间
260 76
|
3月前
|
安全 PHP
PHP 8的Match表达式:更强大的条件控制
PHP 8的Match表达式:更强大的条件控制
|
3月前
|
监控 算法 关系型数据库
分布式事务难题终结:Seata+DRDS全局事务一致性架构设计
在分布式系统中,CAP定理限制了可用性、一致性与分区容错的三者兼得,尤其在网络分区时需做出取舍。为应对这一挑战,最终一致性方案成为常见选择。以电商订单系统为例,微服务化后,原本的本地事务演变为跨数据库的分布式事务,暴露出全局锁失效、事务边界模糊及协议差异等问题。本文深入探讨了基于 Seata 与 DRDS 的分布式事务解决方案,涵盖 AT 模式实践、分片策略优化、典型问题处理、性能调优及高级特性实现,结合实际业务场景提供可落地的技术路径与架构设计原则。通过压测验证,该方案在事务延迟、TPS 及失败率等方面均取得显著优化效果。
244 61
|
3月前
|
SQL 缓存 监控
SQL 质量革命:利用 DAS 智能索引推荐修复慢查询全流程
在数据驱动时代,数据库性能直接影响系统稳定与响应速度。慢查询常因索引缺失、复杂逻辑或数据量过大引发,导致延迟、用户体验下降甚至业务受损。DAS(数据库管理服务)提供智能索引推荐功能,通过分析SQL语句与数据分布,自动生成高效索引方案,显著提升查询性能。本文结合实战案例,详解DAS智能索引推荐原理与使用流程,帮助用户快速定位问题并优化数据库表现,实现系统高效运行。
235 61