本文探讨使用wiremock代理第三方api时，意外收到“javascript禁用”html响应的问题。文章揭示该问题源于将代理指向了需要javascript支持的前端门户而非实际api端点。教程将详细指导如何识别并配置正确的api代理地址，确保wiremock能准确记录和模拟后端api行为，避免常见的配置陷阱。
引言
WireMock作为一个强大的HTTP模拟服务，广泛应用于API开发和测试中，它能够记录、回放和模拟各种HTTP响应。在代理模式下，WireMock允许我们拦截并记录对真实服务的请求和响应，从而为后续的离线测试创建模拟桩。然而，在配置WireMock代理时，有时会遇到意想不到的问题，例如收到与预期API响应不符的HTML页面，甚至提示“JavaScript禁用”的错误信息。本文将深入分析这一常见问题的原因，并提供详细的解决方案。
问题描述：意外的HTML响应
当尝试使用WireMock代理一个第三方API时，用户可能会遇到以下现象：
直接调用第三方API：向实际的第三方服务发出请求，例如：
curl -X GET "http://thrdpary.service.com/api/v2/requests/6396ff4eae78da7b0457f283" -H "authorization: Bearer mytoken" -H "accept: application/json"
此时会得到预期的JSON响应。
通过WireMock代理调用：首先启动WireMock，并将其配置为代理目标服务：
java -jar ~/tools/wiremock/wiremock-jre8-standalone-2.35.0.jar --print-all-network-traffic --verbose --proxy-all https://thrdpary.service.com
然后，通过WireMock的本地端口发起请求：
立即学习“Java免费学习笔记（深入）”；
curl -X GET "http://127.0.0.1:8080/api/v2/requests/6396ff4eae78da7b0457f283" -H "authorization: Bearer mytoken" -H "accept: application/json" -H "Content-Type: application/json"
此时，收到的不再是JSON响应，而是一个HTML页面，其中包含类似“We’re sorry but isp-portal doesn’t work properly without JavaScript enabled. Please enable it to continue.”的错误信息。
WireMock的日志也会明确显示代理返回的Content-Type是text/html，而非预期的application/json：
Response:HTTP/1.1 200server: [nginx]date: [Mon, 12 Dec 2022 13:18:40 GMT]content-type: [text/html]content-length: [3191]...
这表明WireMock成功连接到了目标服务，但目标服务返回的却是前端页面的内容。
根源分析：代理目标误区
导致上述问题的原因在于WireMock的–proxy-all参数指向了一个前端Web门户（例如，一个需要浏览器渲染和JavaScript支持的用户界面），而不是实际提供API服务的后端API端点。
千帆AppBuilder
百度推出的一站式的AI原生应用开发资源和工具平台，致力于实现人人都能开发自己的AI原生应用。
174 查看详情 
许多现代Web应用采用前后端分离架构，前端应用（如Vue、React、Angular构建的单页应用）和后端API服务可能部署在不同的子域名或路径下。例如，thrdpary.service.com可能是一个面向用户的Web界面，而api.thrdpary.service.com才是真正的API接口。
当WireMock代理到thrdpary.service.com时，它实际上是在请求该域名的根路径或默认页面，而这个页面通常会返回一个HTML文档，其中包含用于加载前端应用资源的标签。由于curl命令或WireMock本身不具备浏览器环境来执行JavaScript，前端应用无法正常加载，从而显示“JavaScript禁用”的提示信息。
解决方案：精准定位API端点
解决此问题的关键在于识别并指定正确的API服务域名或子域名作为WireMock的代理目标。
在上述案例中，问题在于将–proxy-all指向了https://thrdpary.service.com，而正确的API端点实际上位于https://api.thrdpary.service.com。
因此，修正后的WireMock启动命令应为：
java -jar ~/tools/wiremock/wiremock-jre8-standalone-2.35.0.jar --print-all-network-traffic --verbose --proxy-all https://api.thrdpary.service.com
通过将–proxy-all参数的值从https://thrdpary.service.com更改为https://api.thrdpary.service.com，WireMock将直接代理到API服务，从而获取到预期的JSON响应，而不是前端HTML页面。
重要提示与最佳实践
HTTPS代理到HTTP的灵活性：WireMock支持将远程的HTTPS服务代理到本地的HTTP端口。这意味着即使第三方API使用HTTPS，你也可以通过本地的http://127.0.0.1:8080来访问它，WireMock会自动处理HTTPS到HTTP的转换。这在开发和测试环境中非常方便，无需额外的SSL证书配置。
验证API端点：在设置WireMock代理之前，始终建议通过curl或其他HTTP客户端工具直接验证目标API端点。确保该端点返回的是预期的API响应（如JSON、XML），而不是HTML页面。这有助于提前发现代理目标配置错误。
例如，在配置WireMock之前，先尝试直接curl https://api.thrdpary.service.com/api/v2/requests/6396ff4eae78da7b0457f283，确认其返回JSON。
理解服务架构：在进行API代理或模拟时，清晰地了解目标服务的架构至关重要。区分前端应用域名、后端API域名以及可能的静态资源域名，可以避免将代理错误地指向非API服务。
WireMock日志分析：当遇到意外响应时，仔细检查WireMock的日志输出（特别是当使用–print-all-network-traffic和–verbose参数时）。日志中的Content-Type头部信息是判断代理是否命中正确服务类型（API vs. HTML）的关键线索。
总结
在使用WireMock进行API代理和记录时，收到“JavaScript禁用”的HTML响应是一个常见的配置错误。其根本原因在于将WireMock的–proxy-all参数指向了需要JavaScript支持的前端Web门户，而非实际的后端API端点。通过精准识别并配置正确的API服务域名，可以有效解决这一问题，确保WireMock能够准确地捕获和模拟API的真实行为。在未来的实践中，建议开发者在配置代理前，务必验证目标URL是否确实是API端点，并充分利用WireMock的详细日志进行故障排查。
以上就是WireMock代理API时遭遇JavaScript禁用错误：原因与解决方案的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1098962.html
微信扫一扫 
支付宝扫一扫 
