Hi Maxim, Thank you for your reply. My use case is as follows:
After the slice header filter calls ngx_http_next_header_filter the contents of the request headers_out fields will be modified if an If-Range header is valid. The production version of the slice header filter already relies on the modified headers_out fields set by the range filter. My extension needs to know the bounds of the new range IF the If-Range header is valid. So I parse the new content_range value using the ngx_http_slice_parse_content_range function to return the stored values. If this is incorrect, then please tell me how I can know if the If-Range header is valid, preferably without duplicating the code in the range filter, and if it is valid, what the correct range values will be. Parenthetically, the behavior I observe is that the computer headers_out.content_range value IS null terminated EXCEPT when the request is read from a disk cache. In this case, the string IS NOT null terminated and instead, has an 'L' (ASCII decimal value 77) after the length of bytes indicated in the ngx_str_t. The existing ngx_http_slice_parse_content_range function fails with an NGX_ERROR return when the string IS NOT null terminated. Carey Gister ________________________________ From: nginx-devel <nginx-devel-boun...@nginx.org> on behalf of Maxim Dounin <mdou...@mdounin.ru> Sent: Saturday, June 29, 2019 03:32 To: nginx-devel@nginx.org Subject: Re: Bug in ngx_http_slice_filter_module ngx_http_slice_parse_content_range function 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
_______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
