Reason for storing duplicate copies of response header value e.g. content_encoding in headers_out

Maxim Dounin mdounin at
Fri Jul 11 12:20:25 UTC 2014


On Fri, Jul 11, 2014 at 07:50:37PM +0800, Rv Rv wrote:

> Nginx stores the response headers in the headers ngx_http_headers_out_t
> ngx_list_t                        headers
>  and also for certain headers , in a corresponding variable in headers_out
> e.g.     ngx_table_elt_t                  *content_encoding;
> The body filter e.g. gunzip  operate only on content_encoding 
> variable.
> So after the gunzip filter executes, the content_encoding value 
> in the headers variable will be gzip (because the response was 
> received as compressed and the content encoding was gzip) but 
> the value of content_encoding variable will be blank because the 
> gunzip filter would have decompressed the content and therefore 
> the content encoding is no longer gzip.
> Are all the body filters than expected to look at the variable 
> within the headers_out structure  ? If so what is the use case 
> of maintaining (possibly) different values for the same headers 
> at different places

In the gunzip filter, you may notice the following:

    r->headers_out.content_encoding->hash = 0;
    r->headers_out.content_encoding = NULL;

This does two things:

1. Clears the "hash" value of the header in the headers list.  For 
response headers this means that the header is to be ignored.  See 
ngx_http_header_filter() to find out how it's handled.

2. Clears the r->headers_out.content_encoding pointer, to make 
other filters know that there is no Content-Encoding headers.

This is basically identical to what various ngx_http_clear_xxx() 
macros do, see src/http/ngx_http_core_module.h.

Maxim Dounin

More information about the nginx mailing list