提琴手更改壓縮請求導致失敗

我有一個應用程序發送壓縮HTTP POST。隨着Fiddler運行，請求失敗，因爲服務器無法解壓縮主體。關閉Fiddler消除了這個問題。有任何想法嗎？提琴手更改壓縮請求導致失敗

2014-10-29 Schultz9999

我從來沒有遇到過這個問題。在Fiddler中，點擊「幫助」>「發送反饋」。發送包含您的流量的SAZ文件，如果這裏的小提琴手出現問題，我很樂意解決這個問題。 – EricLaw 2014-10-29 19:27:11

需要注意的是：你沒有勾選Fiddler工具欄上的'Decode'按鈕，是嗎？如果是這樣，提琴手將解壓縮請求正文並更新標題。正常運行的服務器不會有問題，但如果服務器有問題，所有投注都關閉。 – EricLaw 2014-10-29 19:30:04

解碼按鈕沒有被點擊，即解碼被禁用。 – Schultz9999 2014-10-29 20:31:15

在捕獲提供，請求體被壓縮兩次（gzip，然後再次gzip），但Content-Encoding頭僅Content-Encoding: gzip錯誤地列出。

請求的Content-Length頭也是不正確的：它是Content-Length: 141但發送到服務器主體實際上是在長度164字節。原始主體長度爲159字節，第一個壓縮過程將其縮小爲長度爲141字節，並且當已壓縮的內容被重新壓縮時，其長度將增長爲164字節。

默認情況下，Fiddler不會關心雙重壓縮的內容或無效的Content-Encoding標頭，因爲它不會嘗試解壓請求主體，除非您告訴它這樣做。我能想到的唯一解釋是，也許你在FiddlerScript中寫了一些規則，它是盲目地壓縮請求主體並導致這個問題。另一個可能的原因是，當閱讀此請求時，Fiddler會抱怨無效的Content-Length標題，並且它沒有表明請求正文在Fiddler本身內部被修改。

來源

2014-10-30 15:02:52 EricLaw

原來，如果有'Content-Encoding：gzip'頭文件存在，腳本會自動壓縮/壓縮正文。 Fiddler按照預期爲每一個請求都做了這樣的事情，而不僅僅是那些在作曲家手工製作的人。 – Schultz9999 2014-11-03 17:58:01

FWIW，您可以檢查'oSession.oFlags.ContainsKey（「X-FROM-BUILDER」）'來查看請求是否來自Composer。 – EricLaw 2014-11-03 19:39:13

啊！大！謝謝！ – Schultz9999 2014-11-04 17:39:32

提琴手更改壓縮請求導致失敗

回答

相關問題