nginx中g(shù)zip_types匹配content-type的方式

更新時間：2024年05月14日 10:48:42 作者：u010971572

這篇文章主要介紹了nginx中g(shù)zip_types匹配content-type的方式,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教

1.背景

我們系統(tǒng)中有一個功能，可以配置content-type類型來決定是否打開gzip壓縮。

這個配置與nginx官方的gzip_type不同的地方在于，nginx官方的是寫死在配置文件中的，所有請求都生效；我們自研的是，不同用戶的gzip_type可以不同。

最近發(fā)現(xiàn)一個問題

content-type配置為：image/jpeg，但是后端響應(yīng)的Content-Type為"

image/jped;charset:UTF-8"時，由于代碼中是將配置的content-type與響應(yīng)頭中字符串作精確比較，因此，上述場景，并不能正確打開gzip功能。

nginx對此是如何處理的呢？

后端響應(yīng)的Content-Type保持為image/jped;charset:UTF-8。

1、配置gzip_type 如下，gzip生效：

gzip_type image/jpeg;

2、配置gzip_type如下，gzip不生效：（nginx官方文檔中也沒有提及下面的配置方法）

gzip_type "image/jpeg;charset:UTF-8";

2.nginx處理流程

在進行header_filter時，對content-Type做了校驗：

static ngx_int_t
ngx_http_gzip_header_filter(ngx_http_request_t *r)
{
    ngx_table_elt_t       *h;
    ngx_http_gzip_ctx_t   *ctx;
    ngx_http_gzip_conf_t  *conf;

    conf = ngx_http_get_module_loc_conf(r, ngx_http_gzip_filter_module);

    if (!conf->enable
        || (r->headers_out.status != NGX_HTTP_OK
            && r->headers_out.status != NGX_HTTP_FORBIDDEN
            && r->headers_out.status != NGX_HTTP_NOT_FOUND)
        || (r->headers_out.content_encoding
            && r->headers_out.content_encoding->value.len)
        || (r->headers_out.content_length_n != -1
            && r->headers_out.content_length_n < conf->min_length)
            // ngx_http_test_content_type中對content_type做了校驗
        || ngx_http_test_content_type(r, &conf->types) == NULL
        || r->header_only)
    {
        return ngx_http_next_header_filter(r);
    }
    ...
    }

ngx_http_test_content_type定義如下：

void *
ngx_http_test_content_type(ngx_http_request_t *r, ngx_hash_t *types_hash)
{
    u_char      c, *lowcase;
    size_t      len;
    ngx_uint_t  i, hash;

    if (types_hash->size == 0) {
        return (void *) 4;
    }

    if (r->headers_out.content_type.len == 0) {
        return NULL;
    }

    len = r->headers_out.content_type_len;

    if (r->headers_out.content_type_lowcase == NULL) {

        lowcase = ngx_pnalloc(r->pool, len);
        if (lowcase == NULL) {
            return NULL;
        }

        r->headers_out.content_type_lowcase = lowcase;

        hash = 0;

        for (i = 0; i < len; i++) {
            c = ngx_tolower(r->headers_out.content_type.data[i]);
            hash = ngx_hash(hash, c);
            lowcase[i] = c;
        }

        r->headers_out.content_type_hash = hash;
    }

    return ngx_hash_find(types_hash, r->headers_out.content_type_hash,
                         r->headers_out.content_type_lowcase, len);
}

可以看出，將content-type頭域內(nèi)容轉(zhuǎn)換為了小寫，并使用了r->headers_out.content_type_len長度的內(nèi)容，與配置的types進行比較。

但是針對第1種情況，配置和實際響應(yīng)頭明明是不相等的啊，是這么匹配成功的？

使用gdb打斷點，發(fā)現(xiàn)

r->headers_out.content_type為：
{len = 24, data = “image/jpeg;charset=UTF-8”}
但是，
r->headers_out.content_type_len卻是10！這個與上面為什么不一致呢？

找到設(shè)置content_type的地方：

static ngx_int_t
ngx_http_set_content_type_header(ngx_http_request_t *r,
    ngx_http_lua_header_val_t *hv, ngx_str_t *value)
{
    ngx_uint_t          i;

	// 此時，r->headers_out.content_type_len與 value->len 還是相等的
    r->headers_out.content_type_len = value->len;


#if 1

    for (i = 0; i < value->len; i++) {
        if (value->data[i] == ';') {
        	// 找到第一個分號，然后修改了r->headers_out.content_type_len
            r->headers_out.content_type_len = i;
            break;
        }
    }
#endif

    r->headers_out.content_type = *value;
    r->headers_out.content_type_hash = hv->hash;
    r->headers_out.content_type_lowcase = NULL;

    value->len = 0;

    return ngx_http_set_header_helper(r, hv, value, NULL, 1);
}

可以看出，nginx只使用了Content-Type響應(yīng)頭中第一個分號前的內(nèi)容進行匹配。