Bug in request.headers_out initialization?

Fasihullah Askiri fasihullah.askiri at gmail.com
Wed Nov 23 16:46:56 UTC 2011


Thanks for the prompt reply.

That makes it a lot clearer, is hash = 1 used to indicate that the
lowcase_key isnt initialized (meaning you shouldnt try to look it up the
headers_in_hash) or any other value like 0 is also used?
I basically need the lowcase headers, I am just reusing the key, am I good
with just checking for 1 or should I do something else? [I want to use the
available value instead of re-evaluating]

Thanks again...

On Wed, Nov 23, 2011 at 10:10 PM, Igor Sysoev <igor at sysoev.ru> wrote:

> On Wed, Nov 23, 2011 at 10:04:06PM +0530, Fasih wrote:
> > Hi
> >
> > I have a plugin that uses request.headers_out.headers, I use the
> > lowcase_key of the element for something. However, recently while
> debugging
> > a crash I noticed that the lowcase_key isnt always initialized
> > [e.g.  src/http/modules/ngx_http_userid_filter_module.c:424,
> > set_cookie->lowcase_key isnt set(nor initialized)] I would have taken
> that
> > as a bug but noticed that there are other places
> > [src/http/modules/ngx_http_headers_filter_module.c] where lowcase_key
> isnt
> > initialized. However, in all the three instances, header.hash is
> > initialized to 1.
> >
> > So, the question is:
> > 1. Does hash = 1 necessarily imply that lowcase_key isnt initialized?
> > 2. Should lowcase_key have been initialized and this is a bug [in which
> > case I can walk through the code and submit a patch]
> > 3. Why is this done?
>
> lowcase_key is used in r->headers_in only to find them in headers_in_hash.
>
>
> --
> Igor Sysoev
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>



-- 
+Fasih

*Wisdom doesn't automatically come with old age. Nothing does - except
wrinkles. It's true, some wines improve with age. But only if the grapes
were good in the first place*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20111123/e5cf4c94/attachment.html>


More information about the nginx-devel mailing list