综合欧美日韩,日韩电影限制级,亚洲精品无码一区

盤點Telerik Fiddler Everywhere解決的五大開發調試問題

翻譯|行業資訊|編輯：龔雪|2024-11-19 10:47:06.570|閱讀 109 次

概述：本文將為大家介紹壓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 = "http://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 = "http://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 = "http://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 = "http://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中重試的請求現在顯示如下：