On Thu, Dec 22, 2011 at 11:17 PM, Maxim Dounin <mdounin@mdounin.ru> wrote:
>
> Yes, this is exactly the reason why headers in r->headers_in are
> null-terminated (as well as e.g. arguments in config parsing
> functions). This saves memory allocations and data copying
> if/when these strings will be used when null-terminated strings
> are required for external interfaces (and simplifies some internal
> code as well).
>
> In typical (and the only one as of vanilla nginx) case of headers
> being read from client it costs nothing. In other cases it
> usually means reserving another byte at configuration stage, which
> isn't something overwhelming either.
>
[snip]
>
> Non-null-terminated headers in r->headers_in *will* break nginx,
> ngx_http_gzip_ok() isn't the only place which relies on
> r->headers_in headers being null-terminated. Take a look e.g. at
> ngx_http_dav_module.c.
>
Okay, I'll ensure the header value strings null-terminated in my code.
Thanks for your explanation! :)
Thanks!
-agentzh
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel