【问题标题】:Spring Boot request Parameters not decoding '+'Spring Boot 请求参数不解码 \'+\'
【发布时间】:2022-11-19 09:56:40
【问题描述】:

此问题仅适用于我们在一个环境中的 Spring Boot 服务器的几个实例。服务器在三个不同的环境 (DEV/TEST/PROD) 中运行多个实例。以下情况在 DEV 和 PROD 以及本地都可以正常工作。它在测试中不起作用。

搜索最后带有“+”的用户名未被我们的服务器正确解码。前端的 axios GET 调用发出搜索请求,如下所示:

搜索参数:username+

GET 请求看起来像这样:https://tst.blackrock.com/atmosportal/api/search?search=username%2B

在所有其他环境中,我们的 Spring Boot 控制器能够立即将请求参数 %2B 解码为 +。因此该服务将按预期搜索 username+。然而,在我们的测试环境中,它搜索username%2B

知道为什么会这样吗?

【问题讨论】:

  • 最好提供minimal reproducible example。否则很难回答你的问题。
  • 如果您确定相同的构建已部署到与其他环境一样的 TEST,那么我会开始怀疑是您服务器前面的某些东西导致了问题。负载均衡器,也许?您确定在每个环境中都以相同的方式发出请求吗?

标签: javascript spring-boot uri decode urlencode


【解决方案1】:

没有任何源代码,如果不检查 Spring 应用程序实际发生了什么,真的很难说。无论如何,既然你要求“一些想法”:

  1. 排除任何外部原因——检查真正作为请求的 URL 到达 Spring 应用程序的内容。在 Servlet Dispatcher 进行调试。

  2. 排除 Spring 的内层在它到达端点之前执行它。这意味着,调试您的端点本身。

  3. 此时,重要的是您如何从请求中获取价值。是@RequestParam吗?类型只是一个字符串吗?还是在解析 Spring 的功能之外后以某种方式从 URL 中获取?

    根据环境之间开始不同的点,它要么是 Spring 本身的配置(更有可能),要么是一些预处理(不太可能干扰 URL 参数编码)。

    因此,请查看每个环境中活动的配置文件、有条件地活动的 bean、添加到链中的额外 Servlet 过滤器等。其中一些在 TEST 环境中活动的配置文件可能会意外地对参数进行双重编码,或者相反 - 对于其他 2 个环境,可能有一个解码参数的过滤器,但在 TEST 环境中被禁用。

    那就是说:我来到你的问题是为了寻找一个答案,为什么 Spring 没有解码(取消转义)查询参数。

【讨论】:

    猜你喜欢
    • 2021-07-15
    • 1970-01-01
    • 2022-11-28
    • 2019-03-04
    • 1970-01-01
    • 2020-07-09
    • 1970-01-01
    • 1970-01-01
    • 2019-10-07
    相关资源
    最近更新 更多