盘点Telerik Fiddler Everywhere解决的五大开发调试问题-控件新闻-慧都网

盘点Telerik Fiddler Everywhere解决的五大开发调试问题

翻译|行业资讯|编辑：龚雪|2024-11-19 10:47:06.570|阅读 7 次

概述：本文将为大家介绍压Web调试代理工具Telerik Fiddler Everywhere可以解决的5大开发调试问题，欢迎下载最新版工具体验！

Telerik Fiddler Everywhere是一个安全的、现代的Web调试代理，适用于macOS、Windows和Linux，可用于测试端到端行为的可信调试工具。它的强大之处在于可以响应到达浏览器之前修改响应，以测试和调试web应用程序。Fiddler Everywhere为Web、移动和桌面调试提供了一种简单的方法，可以节省大量的时间和成本。

Telerik Fiddler Everywhere提供的功能允许您修改、模拟、过滤和自动处理HTTP(S)流量，开发人员可以通过动态更改请求和响应来模拟各种场景。Fiddler的规则系统是高度可定制的，并且在处理网络流量时提供了很大的灵活性。本文将演示使用Telerik Fiddler Everywhere可以解决的五大调试问题。

获取Telerik Fiddler Everywhere新版下载

Telerik_KendoUI技术交流群（QQ）：726377843

1. 语法错误

语法错误是在开发过程中引起bug的主要原因之一，虽然有复杂的IDE工具用于维护手动编写的代码库，但是当语法错误出现在对在线API的调用中或作为接收到的HTTPS响应的一部分时，很难查明语法错误。

Fiddler headers文件和body检查器是跟踪这类错误的好地方，让我们通过一个示例应用程序来演示这一点，该应用程序调用公共NASA API来获取当天的Day (APOD)图片。

我们使用的初始来源如下：

<html>
<head>
<script>
let nasa_endpoint = "//api.nasa.gov/planetary/apod?1&api_key=";
let api_key = "DEMO_KEY";
let apod = fetch(nasa_endpoint + api_key)
.then((response) => response.json())
.then(data => {
document.getElementById('img').src = data['url'];
})
</script>
</head>
<body>
<img id="img"/>
</body>
</html>

为了演示，上面的页面在本地https服务器上运行，地址为192.168.100.4:8080。

在使用Fiddler的浏览器捕获模式时，我们可以立即看到应用程序加载了，但是对NASA API的获取请求失败，状态码为400 （Bad request）。

双击会话进一步显示服务器的响应消息，这表明我们使用了不正确的字段。现在可以使用Request选项卡中的Params检查器来进一步分析传递的查询参数。这里，我们的API端点包含一个名为“1”的附加键，它没有值——这导致了问题。

虽然状态码400不是那么具有描述性，但有时API将帮助我们使用更具体的状态码来识别问题。重写上面的代码片段，以便现在它使用正确的端点。但是，这次将有意地在所需API密钥的值中引发语法错误。

<script>
let nasa_endpoint = "//api.nasa.gov/planetary/apod?api_key=";
let api_key = "WRONG_KEY"
let apod = fetch(nasa_endpoint + api_key)
.then((response) => response.json())
.then(data => {
document.getElementById('img').src = data['url'];
})
</script>

这一次，NASA API返回状态码403（未授权）。默认情况下，Fiddler Everywhere配置为显示和突出显示状态码4xx和5xx的会话，以便更容易地检测有问题的会话（如果需要，您可以在流量网格中显示和隐藏不同的列）。

上面立即显示问题在使用的API密钥值内，开发人员可以快速修复。

2. 逻辑错误

像语法错误一样，当我们的代码库或API本身出现逻辑错误时，一个问题就会出现并破坏我们的web应用程序。

稍微修改一下上面的例子：

<script>
let nasa_endpoint = "//api.nasa.gov/planetary/apod?api_key=";
let api_key = "DEMO_KEY"
let apod = fetch(nasa_endpoint + api_key)
.then((response) => response.json())
.then(data => {
document.getElementById('img').src = data['title'];
})
</script>

你注意到逻辑错误了吗？这不是显而易见的。这里的问题是基于来自NASA端点的结果，它返回一个具有多个键的对象，包括指向图像和缩略图的URLs。在这个特定的例子中，我们的JS代码使用title键的值，并将其分配为HTML图像的源。错误可能不会立即被检测到——对NASA API的初始调用按预期工作。但是，在Fiddler中运行上述代码将显示以下内容：

明确在//192.168.100.4:8080上运行应用程序，所以第一个会话是预期的。在内部应用程序调用//api.nasa.gov/planetary/apod，因此这也是另一个预期的会话。

但是应用程序有一个没有正确加载的图像，并且我们看到第三个会话返回状态404 （not Found）。这是应该通过JSON键值对中包含的URL构造的会话，但是我们可以立即看到添加的查询参数不是预期的HTTP地址（指向JPG图像），而是包含其他信息的字符串。

而在简化的场景中，问题是由我们自己的代码库中的逻辑错误引起的（因为我们使用了data["title"]替代data["url"]），同样类型的问题可能是后端服务器故障的结果。例如，我们可以在代码库中调用正确的属性，但其值可能会被服务器API改变。在这两种情况下，Fiddler都允许您快速过滤和检测该信息并应用所需的修复。

最后，运行适当的API调用。

<script>
let nasa_endpoint = "//api.nasa.gov/planetary/apod?api_key=";
let api_key = "DEMO_KEY"
let apod = fetch(nasa_endpoint + api_key)
.then((response) => response.json())
.then(data => {
document.getElementById('img').src = data['url'];
})
</script>

现在我们可以看到所有预期的API调用，Fiddler甚至可以预览图像或HTML页面。

3. 执行错误（带有规则的错误模拟）

在前面的小节中，我们讨论了如何使用Fiddler来检测web应用程序中的语法和逻辑错误。

但是，您不必等到应用程序崩溃（特别是在生产环境中）才测试是否有恢复机制，或者是否向最终用户传递了正确的信息。

在这里，您可以使用Fiddler调试各种问题，模拟状态码和加载替代响应，来充分测试您的web应用程序处理不同场景的能力。

Fiddler最强大的功能之一就是它的Rules选项卡，简单地说，这个应用程序部分使您能够调试、修改、过滤和/或完全模拟会话。

在使用小天文应用程序时，我们可以使用规则来模拟各种状态码。您不需要访问后台——请求和响应的修改发生在中间，这就是为什么像Fiddler这样的工具被称为MITM代理（中间人）。

例如：

1. 捕获来自APOD应用程序的流量。

2. 打开上下文菜单并使用Add New Rule特性。

3. 在Fiddler 的 Rules Builder中，创建使用Return预定义响应操作的新规则。

通过以上步骤，您可以在几秒钟内模拟服务器行为或测试不同的场景。不需要修改后端，甚至不需要访问服务器！Fiddler站在中间，允许您模拟web应用程序的生产或过渡环境。

虽然上面的示例展示了如何使用预定义的HTTP响应列表（模拟不同的状态码），但您也可以创建完全自定义的响应，这使您能够测试潜在的修复或新设计——同样无需在应用程序或服务器中进行更改。

例如：

从目标页面捕获流量。
打开上下文菜单并使用Add New Rule特性。
在Fiddler的 Rules Builder中，创建一个使用Return Manual Response或Return File操作的新规则。

4. 运行时更改和错误

Telerik Fiddler Everywhere最强大的功能之一是它能够在HTTP会话执行期间“暂停”流量并对其进行修改，可以使用Fiddler暂停执行一个目标API调用，然后修改它的操作，以修复错误或展示一个全新的现实，Fiddler社区很熟悉这个特性——Fiddler断点。

在Fiddler Everywhere中，您可以创建两种类型的断点。第一个将在HTTP请求发送到服务器之前暂停会话，而第二个将在HTTP响应发送到客户端之前暂停会话。

上述特性的直接效果是，您可以在实时流量到达目标目的地之前对其进行修改。这里的可能性是无穷无尽的——您可以测试任何API调用，看看它如何处理不同的headers、cookies和bodies，还可以在不访问客户端或服务器的情况下“破解”一个页面，所需要的只是Fiddler作为代理站在中间并使用断点。

让我们通过一个快速演示来可视化这个过程，将使用一个知名的在线服务来模拟缓存的端点。

1. 启动Fidder Everywhere并使用浏览器捕获模式。

2. 打开一个模拟缓存响应（如//httpbin.org/cache）的端点。

如果在HTTP请求中存在If-Modified-Since header或If-None-Match，则返回304，否则它返回与GET（200）相同的结果。如果这是您第一次访问该页面，它将显示200，刷新页面，您将收到状态304。

我们将使用Fiddler暂停请求执行，并在上述headers到达服务器之前显式地添加或删除它们。

3. 从捕获的会话打开上下文菜单，并使用“Add New Rule”。

4. 在Rules Builder中，添加名为“Set Breakpoint”的操作，并将其指定为在 “Before Sending a Request”使用。

5. 返回到浏览器并刷新页面。

此时，Fiddler将暂停HTTP请求的执行。一旦请求暂停，您就可以加载request检查器并使用Raw选项卡进行任何修改。

6. 最后取消暂停请求，会话将继续执行。

通过上面的代码，我们刚刚做了一个运行时修改，改变了客户端和服务器的操作。如前所述，在这两个目的地都没有实际的改变。

5. 测试性能和安全性

许多现代web应用程序使用各种可能导致性能或安全问题的功能，一个典型的例子是身份验证，它通常链接到需要为客户端提供不间断服务的后端服务器。测试服务器的漏洞和弱点，以帮助防止潜在的攻击，是开发人员的一项重要任务。

Fiddler Everywhere允许您测试服务器端点是否存在安全问题，例如下面的示例。您可以通过遵循最佳实践来测试应用程序是否具有安全的身份验证过程，例如为连续请求创建指数重试。

考虑这样一个场景：web应用程序试图使身份验证请求失败。服务器（在本例中为HTTPBin）始终返回状态500，提示我们的应用程序不断重试。

使用Fiddler，我们可以从应用程序（进程名节点：16176）捕获流量，并立即识别几个问题：

重新尝试的请求似乎永无止境。
重试的请求在一段特定时间后执行，缺乏指数回退策略。

您可以从Request Time列中注意到这一点，或者在Fiddler Everywhere中选择所有会话，然后切换到Overview选项卡，确认每个请求之间没有指数计时。

这些问题可能导致严重的问题，例如如果服务器长时间不可用，应用程序的用户将不断触发许多请求，可能导致自己造成的攻击，使服务器无法响应。

从Fiddler获得信息后，我们可以审查申请。演示应用使用了一个著名的NPM库retry（它设置重试的次数和类型）和axios（用于执行请求），快速的代码检查显示重试操作配置了特定的参数。

const retry = require('retry');

function faultTolerantHttpRequest(URL, cb) {
// Initialize a retry operation with custom settings
const operation = retry.operation({
forever: true, // Retries forever
factor: 0, // Exponential backoff factor
minTimeout: 100, // Minimum timeout (in milliseconds)
maxTimeout: 10 * 100, // Maximum timeout (in milliseconds)
randomize: false, // Randomize the timeouts
});

这个配置证实了我们的发现——重试被显式地设置为“forever”，指数回退因子被设置为0，这意味着没有指数计时。为了解决这个问题，我们删除了 “forever”设置，为重试的最大可能次数设置了严格的限制，实现了指数回退策略并调整了超时值。

const operation = retry.operation({
retries: 5, // Limits the number of retries to 5
factor: 2, // Sets an exponential timing that adds two additional times after each retry
minTimeout: 1000
maxTimeout: 60 * 1000
randomize: false
});

有了这些更改，Fiddler中重试的请求现在显示如下：