<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 8 Jul 2020, at 07:14, webber <<a href="mailto:nginx-forum@forum.nginx.org" class="">nginx-forum@forum.nginx.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi,<br class=""><br class="">Thanks for your reply. I have tried the patch that removes the original<br class="">Accept-Ranges in slice filter module, but it is not work as my expected. <br class="">Because I think response header `Accept-Ranges` should be added if client<br class="">send a range request.<br class=""><br class="">Actually, in my production environment, my upstream server is Apache<br class="">TrafficServer, and according to RFC 7233, section 2.3:<br class="">Accept-Ranges(<a href="https://tools.ietf.org/html/rfc7233#section-2.3" class="">https://tools.ietf.org/html/rfc7233#section-2.3</a>) , I think<br class="">original Accept-Ranges header should not be removed in all case. I changed<br class="">your patch as follow, original Accept-Ranges header will be removed just<br class="">for no-range request , that will work for me, could you please review that?<br class=""></div></div></blockquote><div><br class=""></div><div>RFC 7233 does not require a server to send Accept-Ranges at all, and certainly</div><div>does not require it to send the header with a 206 response. Indeed Apache does</div><div>send Accept-Ranges both with 200 and 206, but nginx only sends it with 200.</div><div>This is how nginx works and I don’t think changing this only for the slice module</div><div>is a good idea. By the way, the example of a 206 response in RFC 7233 does</div><div>not have the Accept-Ranges too: <a href="https://tools.ietf.org/html/rfc7233#section-4.1" class="">https://tools.ietf.org/html/rfc7233#section-4.1</a>.</div><div><br class=""></div><div>The rule nginx follows is this. Accept-Ranges should be sent by a party that does</div><div>ranges and is a way to signal the support for ranges. If ranges are done by the nginx</div><div>range filter, it should add the header. The Accept-Ranges that came from the</div><div>upstream server is unrelated to what the range filter is doing even if it’s exactly the</div><div>same header. That’s why the existing Accept-Ranges header should be removed</div><div>anyway.</div><div><br class=""></div><div>Another question is whether the range filter should add a new header for both</div><div>200 and 206 or only for 200. The way it currently works for any response (not only</div><div>a slice response) is to add Accept-Ranges only for 200. Whether this should be</div><div>changed nginx-wise is a totally different question and I personally don’t think it makes</div><div>sense.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">diff --git a/src/http/modules/ngx_http_slice_filter_module.c<br class="">b/src/http/modules/ngx_http_slice_filter_module.c<br class="">index c1edbca2..570deaa5 100644<br class="">--- a/src/http/modules/ngx_http_slice_filter_module.c<br class="">+++ b/src/http/modules/ngx_http_slice_filter_module.c<br class="">@@ -180,6 +180,11 @@ ngx_http_slice_header_filter(ngx_http_request_t *r)<br class=""> r->headers_out.content_range->hash = 0;<br class=""> r->headers_out.content_range = NULL;<br class=""><br class="">+ if (!r->headers_in.range) {<br class="">+ r->headers_out.accept_ranges->hash = 0;<br class="">+ r->headers_out.accept_ranges = NULL;<br class="">+ }<br class="">+<br class=""> r->allow_ranges = 1;<br class=""> r->subrequest_ranges = 1;<br class=""> r->single_range = 1;<br class=""><br class="">Posted at Nginx Forum: <a href="https://forum.nginx.org/read.php?2,288569,288627#msg-288627" class="">https://forum.nginx.org/read.php?2,288569,288627#msg-288627</a><br class=""><br class="">_______________________________________________<br class="">nginx mailing list<br class=""><a href="mailto:nginx@nginx.org" class="">nginx@nginx.org</a><br class="">http://mailman.nginx.org/mailman/listinfo/nginx<br class=""></div></div></blockquote></div><br class=""></div></body></html>