header value null termination?

Maxim Dounin mdounin at mdounin.ru
Mon Aug 25 14:32:50 UTC 2014


On Fri, Aug 22, 2014 at 12:30:22AM +0100, Steven Hartland wrote:

> I'm creating a module in which I needed to set some
> of the standard headers e.g. Content-Range and Range.
> Looking through the core source code the standard way
> to do this seems to be something like this:-
> r->headers_in.range->value.len =
>    ngx_sprintf(r->headers_in.range->value.data,
>        "bytes %O-%O/%O",
>        range->start, range->end - 1,
>        r->headers_out.content_length_n)
>        - r->headers_in.range->value.data;
> This appears to write a string to value.data which
> is not \0 terminated hence when interacting with
> functions such as ngx_http_range_parse unpredictable
> behaviour follows as it expects the range header to
> be null terminated.
> So the question is:-
> Should header values be null terminated or should
> functions such as ngx_http_range_parse be updated
> to deal with non-null terminated strings?

The answer is: no.

In general, strings in nginx are not null terminated, and there is 
no need to null-terminated them.  In some cases though strings are 
guaranteed to be null-terminated - notably, configuration 
directive arguments are always null-terminated, as well as input 
headers.  The ngx_http_range_parse() uses an input header from 
r->headers_in, and it's guaranteed to be null-terminated.

The problem is in the "sample" code you've provided though: it 
tries to modify input headers in r->headers_in.  This is wrong 
thing to do.

Maxim Dounin

More information about the nginx-devel mailing list