WSO2 Micro Integrator通过<call>中介调用API时出现400错误

问题场景 #

通过Postman直接调用原生API可正常返回200状态码，但使用WSO2 Micro Integrator调用时返回400错误，错误响应如下：

<html>
<body>
    <h1>400 Bad Request</h1>
    Your browser sent an invalid request.
</body>
</html>

代理服务的inSequence配置如下：

<inSequence>
    <enrich>
        <source clone="true" type="body"/>
        <target property="jwtToken" type="property"/>
    </enrich>
    <class name="TokenClassGen.TokenClassGen"/>
    <property expression="fn:concat('Bearer ', get-property('jwtToken'))" 
              name="Authorization" 
              scope="transport" 
              type="STRING"/>
    <call>
        <endpoint>
            <http method="get" uri-template="https://NATIVE-URL">
                <suspendOnFailure>
                    <initialDuration>-1</initialDuration>
                    <progressionFactor>-1</progressionFactor>
                    <maximumDuration>0</maximumDuration>
                </suspendOnFailure>
                <markForSuspension>
                    <retriesBeforeSuspension>0</retriesBeforeSuspension>
                </markForSuspension>
            </http>
        </endpoint>
    </call>
    <respond/>
</inSequence>

使用相同令牌和查询参数通过Postman测试正常，现针对以下问题解答：

问题解答 #

1. 400错误的可能原因 #

• 请求头缺失或格式错误：原生API可能依赖Postman自动携带但Micro Integrator未传递的请求头（如Content-Type、User-Agent），或者Authorization头构造异常（比如令牌前后有多余空格、令牌本身格式无效）。
• 请求参数/体传递异常：当前配置通过enrich将请求body存入jwtToken属性后，原请求的查询参数可能未被携带到后端API；自定义类TokenClassGen处理令牌时可能引入无效字符，导致授权信息失效。
• URL模板问题：uri-template中的https://NATIVE-URL如果包含动态参数，未通过Micro Integrator的参数注入机制正确传递，导致URL格式非法。
• 传输层编码差异：Micro Integrator默认的请求编码、HTTP版本（如HTTP/1.1 vs HTTP/2）与原生API期望的不一致，引发请求解析失败。

2. 是否与查询参数编码或请求构造有关 #

是的，这类问题的可能性极高：

• 查询参数编码：Postman会自动对特殊字符（如空格、&、=）进行URL编码，但Micro Integrator若直接传递未编码的参数，会导致URL格式无效触发400。比如原请求的param=hello world，Postman会转成param=hello%20world，但Micro Integrator可能直接传递原始字符串。
• 请求构造问题：当前配置中，enrich操作后原请求的查询参数可能丢失；Authorization头拼接时，jwtToken属性值为空或格式错误，导致授权头无效。另外，若原生API要求GET请求携带特定请求头，而Micro Integrator未正确设置，也会触发400。

3. 配置与调试技巧 #

• 对比请求报文：用抓包工具（如Wireshark、tcpdump）分别捕获Postman和Micro Integrator发送的请求，重点对比请求头、URL、参数编码的差异，定位缺失的头或格式不一致的部分。
• 启用Micro Integrator日志：开启DEBUG级别的HTTP传输日志，查看发送给后端的完整请求详情。在log4j2.properties中添加配置：

  log4j.logger.org.apache.synapse.transport.http.wire=DEBUG
  

• 显式设置必要请求头：在inSequence中补充原生API依赖的请求头，例如：

  <property name="Content-Type" value="application/json" scope="transport" type="STRING"/>
  <property name="User-Agent" value="WSO2-Micro-Integrator" scope="transport" type="STRING"/>
  

• 确保参数正确传递与编码：如果有查询参数，通过uri-template占位符传递，或使用fn:encode-for-uri()函数对参数编码：

  <property expression="fn:encode-for-uri(get-property('param'))" name="uri.var.param" type="STRING"/>
  <http method="get" uri-template="https://NATIVE-URL?param={uri.var.param}"/>
  

• 验证自定义类逻辑：检查TokenClassGen类是否正确生成/处理JWT令牌，确保输出的令牌无多余字符、格式符合标准（无换行、空格）。
• 测试简化版请求：先构造极简inSequence（直接添加正确的Authorization头后调用后端），排除自定义类或enrich操作的干扰，逐步添加逻辑定位问题。

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