Add new cookie into headers_in

agentzh agentzh at
Wed Jan 26 07:47:52 MSK 2011

On Wed, Jan 26, 2011 at 12:31 PM, agentzh <agentzh at> wrote:
> On Tue, Jan 25, 2011 at 8:54 PM, Maxim Dounin <mdounin at> wrote:
>>> I have already read this recommendation in another topic. But
>>> headers_more_module can modify header_in.headers and I wanted to do it
>> The fact that some third-party module does this doesn't mean that
>> it's correct.
> The ngx_headers_more module does use some tricks to get around the bug
> that nginx does not copy the input headers struct into subrequests' in
> a right way :) I won't say that my hack there is not flawless, but I'm
> open to any concrete test cases that can make it fail ;)
> Re michalkraus: if you want to do that, just check ngx_headers_more's
> source code. If it fails for you, just send a mail to me or file a bug
> for my module :)

Sorry, it has nothing to do with ngx_headers_more, it's only related
to the ngx_http_subrequest() function in the nginx core. My hack was
not in the ngx_headers_more module, but in ngx_lua and ngx_echo. These
modules adjust the subrequest struct when issuing a subrequest. My
current way is not perfectly correct:

    /* XXX work-around a bug in ngx_http_subrequest */
    if (r->headers_in.headers.last == &r->headers_in.headers.part) {
        sr->headers_in.headers.last = &sr->headers_in.headers.part;

I should have checked the implementation of ngx_list more carefully
and come up with a saner way to work around that bug. I haven't met
any issues yet but my gut feeling is that it's still not perfect. I'll
look at this closer later.

In short, whether it is valid to modify the input headers depends only
on how subrequests inherit their parents' input headers, no?

Maxim Dounin, you may not agree that it is a bug in
ngx_http_subrequest, but I do. IMHO, saying flatly that something
cannot be done just because how it *is* implemented is boring and no


More information about the nginx mailing list