久久午夜电影网,久久九九免费高清视频,999久久久无码国产精品

Firefox的HTTP內容解壓代碼閱讀

Firefox的HTTP內容解壓代碼閱讀

（轉載請注明來源于金慶的專欄）

參考firefox-2.0.0.4-source

RFC2612 3.5節Content codings, 內容編碼定義了三種內容壓縮方式：
gzip, compress, deflate, 但也可以注冊新的壓縮方式。

找到FireFox中的Http解壓代碼：

Find 'deflate' in 'D:\mozilla\netwerk\streamconv\converters\nsHTTPCompressConv.h' :
D:\mozilla\netwerk\streamconv\converters\nsHTTPCompressConv.h(58): #define HTTP_DEFLATE_TYPE "deflate"

nsHttpCompressConv.h

#define HTTP_DEFLATE_TYPE       "deflate"
#define HTTP_GZIP_TYPE          "gzip"
#define HTTP_X_GZIP_TYPE        "x-gzip"
#define HTTP_COMPRESS_TYPE      "compress"
#define HTTP_X_COMPRESS_TYPE    "x-compress"
#define HTTP_IDENTITY_TYPE      "identity"
#define HTTP_UNCOMPRESSED_TYPE  "uncompressed"

typedef enum    {
        HTTP_COMPRESS_GZIP,
        HTTP_COMPRESS_DEFLATE,
        HTTP_COMPRESS_COMPRESS,
        HTTP_COMPRESS_IDENTITY
    }   CompressMode;

定位到類與方法：

class nsHTTPCompressConv : public nsIStreamConverter

nsHTTPCompressConv::AsyncConvertData(const char *aFromType, ...)
比較類型串，設置解壓模式。例
else if (!PL_strncasecmp(aFromType, HTTP_DEFLATE_TYPE, sizeof(HTTP_DEFLATE_TYPE)-1))
mMode = HTTP_COMPRESS_DEFLATE;

nsHTTPCompressConv::OnDataAvailable(...)
針對不同解壓模式進行解壓。

代碼閱讀：

    switch (mMode)
    {
        case HTTP_COMPRESS_GZIP:
            streamLen = check_header(iStr, streamLen, &rv);
        case HTTP_COMPRESS_DEFLATE:

            break;
        default:

}

HTTP_COMPRESS_COMPRESS沒有進行特別處理？
應該是無法解的，可能LZW解壓算法有專利問題。

Gzip進行頭部處理后就與deflate進行相似的解壓。

case HTTP_COMPRESS_DEFLATE:

if (mMode == HTTP_COMPRESS_DEFLATE)

/* deflate */
else

/* gzip */
break;

deflate與gzip解壓的代碼幾乎相同，應該可以合成一塊代碼。
區別僅有：

deflate使用inflateInit()，而gzip使用inflateInit2()進行初始化，比inflateInit()多一個參數: -MAX_WBITS，表示處理raw deflate數據。因為gzip數據中的zlib壓縮數據塊沒有zlib header的兩個字節。使用inflateInit2時要求zlib庫忽略zlib header。在zlib手冊中要求windowBits為8..15，但是實際上其它范圍的數據有特殊作用，見zlib.h中的注釋，如負數表示raw deflate。
Apache的deflate變種可能也沒有zlib header，需要添加假頭后處理。即MS的錯誤deflate (raw deflate).zlib頭第1字節一般是0x78, 第2字節與第一字節合起來的雙字節應能被31整除，詳見rfc1950。例如Firefox的zlib假頭為0x7801，python zlib.compress()結果頭部為0x789c。

deflate添假頭，與gzip忽略頭部效果應該是一樣的，是否可以合并處理？
能否判斷頭部兩個字節是zlib頭部還是數據？是否有可能raw deflate數據按正常zlib塊處理了而不報錯？

check_header()

參考：GZIP文件格式簡介

1. gz頭：0x1f8b
2. Z_DEFLATED標志：0x08
...
其中FLG.FEXTRA的處理有個錯誤，額外可選項的長度應該是兩個字節的合成：
                mLen = ((uInt) c & 0377) << 8;
應改為
                mLen |= ((uInt) c & 0377) << 8;
因為該額外字段一般在HTTP的應用中不會出現，所以沒有顯現出來。
我已提交：Bugzilla@Mozilla – Bug 383984

注意：GZIP文件格式簡介中的額外字段的格式與rfc1952不一致，多了兩個“選項ID”字節。

還有，
case GZIP_COMMENT:
     if (mFlags & GZIP_COMMENT)

應改為:

case GZIP_COMMENT:
     if (mFlags & COMMENT)

該錯誤已提交，Bugzilla@Mozilla – Bug 382849

zlib可以處理gzip頭部，但所有gz函數都是針對gz文件進行的，沒有直接在內存中處理gzip的，這好象是zlib功能上的一個不足吧？

相關rfc:
rfc1950: ZLIB Compressed Data Format Specification version 3.3
rfc1951: DEFLATE Compressed Data Format Specification version 1.3

（轉載請注明來源于金慶的專欄）

posted on 2007-07-09 12:13 金慶閱讀(2217) 評論(0) 編輯收藏引用所屬分類: 1. C/C++

只有注冊用戶登錄后才能發表評論。
【推薦】100%開源！大型工業跨平臺軟件C++源碼提供，建模，組態！

相關文章: How are dtLinks created in NavMesh C++ parameter passing rules Naming Conventions for Accessors Visual Studio 2019 Compiler Hangs Fbx File Format Identifier 查找內存錯誤 std::thread 中的異常會丟失調用棧用賦值代替 protobuf CopyFrom() vs2017 linux 編譯輸出改成 vs 格式為 LiteIDE 添加選中標記

網站導航: 博客園 IT新聞 BlogJava 博問 Chat2DB 管理

金慶的專欄

公告

留言簿(12)

隨筆分類(502)

隨筆檔案(423)

相冊

搜索

積分與排名

最新評論

閱讀排行榜

評論排行榜