Hello! On Thu, Jun 27, 2019 at 02:01:27AM +0000, Carey Gister wrote:
> The ngx_http_slice_parse_content_range function assumes that the > parsed buffer is null terminated. Since the buffer is an > ngx_str_t, that assumption is false. If, by chance, the buffer > is null terminated it is simply a matter of luck, and not > design. In many cases ngx_str_t is used for null-terminated strings. Most simple example is directive arguments during configuration parsing - while arguments are using ngx_str_t type, they are guaranteed to be null-terminated. Other examples are input headers, and upstream input headers. The latter implies that response Content-Range header will be null-terminated as seen by the slice module - unless you are producing it with some custom module. > In particular, if the headers_out.content_range ngx_str_t was > allocated in the ngx_http_range_filter_module then the buffer > was allocated as a non-zero terminated buffer by ngx_pnalloc. The range filter works after the slice module, hence whatever is set in the headers_out.content_range field by the range filter cannot affect slice module. Further, if slice module ever uses Content-Range header set by the range filter, this would indicate a severe bug, as it is expected to use Content-Range header from a backend response, not Content-Range header from the resulting response to the client. -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
