header value null termination?
Steven Hartland
steven.hartland at multiplay.co.uk
Mon Aug 25 18:56:13 UTC 2014
----- Original Message -----
From: "Maxim Dounin" <mdounin at mdounin.ru>
To: <nginx-devel at nginx.org>
Sent: Monday, August 25, 2014 3:32 PM
Subject: Re: header value null termination?
> 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.
Thanks for the confirming all input headers should be null
terminated, thats good to hear as thats what I did :)
The task I'm trying to achieve is quite a strange thing to be doing,
essentially I'm sending different headers to subrequests than the
original client sent.
I seems the only way to achieve this is to alter sr->headers_in
as in the sample; unless there's another way to do this?
As part of this project I've got a patch which adds the ability
to do range requests from 206 responses to
ngx_http_range_filter_module, is this something that you would
consider upstreaming?
Regards
Steve
More information about the nginx-devel
mailing list