<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Maxim,</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thank you for your reply. <span style="color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;"> My use case is as follows:</span></div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;"><br>
</span></div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;">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.</span></div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;"><br>
</span></div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;">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.</span></div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;"><br>
</span></div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;">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.</span></div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;"><br>
</span></div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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.</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="Signature"><span style="color:black">Carey Gister</span>
<div><span style="color:black"><br>
 </span> </div>
<div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> nginx-devel <nginx-devel-bounces@nginx.org> on behalf of Maxim Dounin <mdounin@mdounin.ru><br>
<b>Sent:</b> Saturday, June 29, 2019 03:32<br>
<b>To:</b> nginx-devel@nginx.org<br>
<b>Subject:</b> Re: Bug in ngx_http_slice_filter_module ngx_http_slice_parse_content_range function</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">Hello!<br>
<br>
On Thu, Jun 27, 2019 at 02:01:27AM +0000, Carey Gister wrote:<br>
<br>
> The ngx_http_slice_parse_content_range function assumes that the <br>
> parsed buffer is null terminated. Since the buffer is an <br>
> ngx_str_t, that assumption is false. If, by chance, the buffer <br>
> is null terminated it is simply a matter of luck, and not <br>
> design.<br>
<br>
In many cases ngx_str_t is used for null-terminated strings. <br>
Most simple example is directive arguments during configuration <br>
parsing - while arguments are using ngx_str_t type, they are <br>
guaranteed to be null-terminated.  Other examples are input <br>
headers, and upstream input headers.  The latter implies that <br>
response Content-Range header will be null-terminated as seen by <br>
the slice module - unless you are producing it with some custom <br>
module.<br>
<br>
> In particular, if the headers_out.content_range ngx_str_t was <br>
> allocated in the ngx_http_range_filter_module then the buffer <br>
> was allocated as a non-zero terminated buffer by ngx_pnalloc.<br>
<br>
The range filter works after the slice module, hence whatever is <br>
set in the headers_out.content_range field by the range filter <br>
cannot affect slice module.  Further, if slice module ever uses <br>
Content-Range header set by the range filter, this would indicate <br>
a severe bug, as it is expected to use Content-Range header from a <br>
backend response, not Content-Range header from the resulting <br>
response to the client.<br>
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/">http://mdounin.ru/</a><br>
_______________________________________________<br>
nginx-devel mailing list<br>
nginx-devel@nginx.org<br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
</div>
</span></font></div>
</div>
</div>
</body>
</html>