range_filter_module get duplicated Accept-Ranges response headers

[Roman Arutyunyan]

Hi,

> On 8 Jul 2020, at 07:14, webber <nginx-forum at forum.nginx.org> wrote:
> 
> Hi,
> 
> Thanks for your reply. I have tried the patch that removes the original
> Accept-Ranges in slice filter module, but it is not work as my expected. 
> Because I think response header `Accept-Ranges` should be added if client
> send a range request.
> 
> Actually, in my production environment, my upstream server is Apache
> TrafficServer, and according to RFC 7233, section 2.3:
> Accept-Ranges(https://tools.ietf.org/html/rfc7233#section-2.3) , I think
> original Accept-Ranges header should not be removed in all case. I changed
> your patch as follow,  original Accept-Ranges header will be removed just
> for no-range request , that will work for me, could you please review that?

RFC 7233 does not require a server to send Accept-Ranges at all, and certainly
does not require it to send the header with a 206 response. Indeed Apache does
send Accept-Ranges both with 200 and 206, but nginx only sends it with 200.
This is how nginx works and I don’t think changing this only for the slice module
is a good idea. By the way, the example of a 206 response in RFC 7233 does
not have the Accept-Ranges too: https://tools.ietf.org/html/rfc7233#section-4.1 <https://tools.ietf.org/html/rfc7233#section-4.1>.

The rule nginx follows is this. Accept-Ranges should be sent by a party that does
ranges and is a way to signal the support for ranges. If ranges are done by the nginx
range filter, it should add the header. The Accept-Ranges that came from the
upstream server is unrelated to what the range filter is doing even if it’s exactly the
same header. That’s why the existing Accept-Ranges header should be removed
anyway.

Another question is whether the range filter should add a new header for both
200 and 206 or only for 200. The way it currently works for any response (not only
a slice response) is to add Accept-Ranges only for 200. Whether this should be
changed nginx-wise is a totally different question and I personally don’t think it makes
sense.

> diff --git a/src/http/modules/ngx_http_slice_filter_module.c
> b/src/http/modules/ngx_http_slice_filter_module.c
> index c1edbca2..570deaa5 100644
> --- a/src/http/modules/ngx_http_slice_filter_module.c
> +++ b/src/http/modules/ngx_http_slice_filter_module.c
> @@ -180,6 +180,11 @@ ngx_http_slice_header_filter(ngx_http_request_t *r)
>     r->headers_out.content_range->hash = 0;
>     r->headers_out.content_range = NULL;
> 
> +    if (!r->headers_in.range) {
> +        r->headers_out.accept_ranges->hash = 0;
> +        r->headers_out.accept_ranges = NULL;
> +    }
> +
>     r->allow_ranges = 1;
>     r->subrequest_ranges = 1;
>     r->single_range = 1;
> 
> Posted at Nginx Forum: https://forum.nginx.org/read.php?2,288569,288627#msg-288627
> 
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20200708/bff04f39/attachment.htm>