Hello! 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 http://nginx.org/ _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
