gzip沒有服務器支持？

我寫了一個最小化和基本解析/ var替換的css服務器。服務器正在使用node.js.gzip沒有服務器支持？

我想gzip我的迴應從這臺服務器。正如在IRC中所說的，node.js目前沒有gzip庫，因此我試圖從命令行手動執行它（因爲我只是在不在緩存中時進行gzip壓縮）。

我正在將文件數據推送到臨時文件，然後使用exec調用'gzip -c -9 -q ' + tempFile。我得到正確的壓縮數據（看來），併發送正確的Content-Encoding標頭爲'gzip'，但Chrome報告：

Error 330 (net::ERR_CONTENT_DECODING_FAILED): Unknown error。

還有一些獨立的gzip測試人員在線也失敗（不僅僅是Chrome）。

我假設這是簡單的東西，我不知道如何爲瀏覽器生成gzip塊，因爲我從來沒有嘗試過手動執行它。

任何幫助將有所幫助。服務器速度非常快，但我需要對內容進行gzip以獲得最終用戶的最佳性能。

謝謝。

UPDATE 我已經驗證了我的Content-Length是正確

來源

2010-02-22 Spot

你有更新的內容長度相匹配的gzip壓縮的大小？這似乎可能會搞砸解碼。

來源

2010-02-22 02:08:37 Sionide21

內容在發送到瀏覽器之前正在被gzip壓縮。瀏覽器沒有正確的長度？但是，我會嘗試。我很絕望。:) – Spot 2010-02-22 02:10:23

他的觀點是，如果您的服務器將預壓縮長度指定爲標題，則會出現非法的HTTP響應。您可以使用Fiddler或類似工具輕鬆檢查標題。 – EricLaw 2010-02-22 02:14:38

好吧，沒有修復它不幸的。 – Spot 2010-02-22 02:33:31

節點依然流血，似乎還沒有一個良好的處理二進制數據。

Node's string encodings是ascii，binary和utf8。 [...]「binary」僅在16位JavaScript字符串字符的的前8位處查找[s]。問題是根據ECMA的字符串是16位字符串。如果您使用UTF-8（這是默認設置），則在讀入字符串時會出現一些規範化，並且會破壞gzip。如果你使用ascii，那顯然是行不通的。

如果使用二進制編碼都讀寫它將工作。 Javascript字符串字符的高8位沒有被使用。如果沒有，請嘗試直接將文件發送到客戶端，而不需要任何加載到Javascript字符串中，也許藉助Node前的代理服務器。

我自己也希望谷歌的V8引擎實現了真正的二進制字符串的數據類型，這樣的建議http://groups.google.com/group/nodejs/browse_thread/thread/648a0f5ed2c95211/ef89acfe538931a1?lnk=gst&q=binary+type#ef89acfe538931a1

CommonJS的還提議Binary/B東西，因爲節點試圖遵循CommonJS的，有一些對未來的希望。

編輯我剛剛發現了包含二進制緩衝區的節點的net2 branch（請參閱src/node_buffer.h）。它似乎是網絡徹底改革的一部分。

來源

2010-02-25 14:54:08 nalply

我的問題實際上證明是一個內容長度問題，但被另一個迂迴問題所阻止。然而你是對的，V8需要把這些東西付諸實施，而且很快！ :)感謝您的迴應。 – Spot 2010-03-22 08:56:51

節點合併了net2分支。您可以在buffer.js中使用Buffer中的二進制數據。 – nalply 2010-03-26 12:44:44

@spot原來的問題仍然有效嗎？ – ordnungswidrig 2010-12-07 19:25:15

gzip沒有服務器支持？

回答

相關問題