[PATCH] During background update, nginx can't add "Range" header

[Roman Arutyunyan]

Hi,

> On 23 Jul 2020, at 08:29, Sangdeuk Kwon <sangdeuk.kwon at quantil.com> wrote:
> 
> # HG changeset patch                                                            
> # User Sangdeuk Kwon <sangdeuk.kwon at quantil.com <mailto:sangdeuk.kwon at quantil.com>>                                
> # Date 1595481798 -32400                                                        
> #      Thu Jul 23 14:23:18 2020 +0900                                           
> # Node ID 90e5ccf7c229322079ba1b61b4241ed69dfc09b2                              
> # Parent  4f30f75dbdf33d6fae9e70086e0df5cbab7db027                              
> During background update, nginx can't add "Range" header                        
>                                                                                 
> If the configuration is "slice enabled" and "proxy_cache_use_stale updating"    
> and "proxy_cache_background_update on",                                         
> nginx can't get "$slice_range" value during background update.                  
> nginx sends request to upstream without "Range" header.                         
> The re-fetched content is saved by cache key of absent "$slice_range".          
> So, nginx always serves stale content even though after re-fetching new content.

This is correct.  The slice module does not work with background updates.

>                                                                                 
> slice 1k;                                                                       
> proxy_cache_use_stale updating;                                                 
> proxy_cache_background_update on;                                               
> proxy_cache_key "$host$uri[$slice_range]                                        
>                                                                                 
> diff -r 4f30f75dbdf3 -r 90e5ccf7c229 src/http/modules/ngx_http_slice_filter_module.c
> --- a/src/http/modules/ngx_http_slice_filter_module.c   Tue Jul 21 20:34:29 2020 +0300
> +++ b/src/http/modules/ngx_http_slice_filter_module.c   Thu Jul 23 14:23:18 2020 +0900
> @@ -400,9 +400,12 @@                                                            
>      ngx_http_slice_loc_conf_t  *slcf;                                          
>                                                                                 
>      ctx = ngx_http_get_module_ctx(r, ngx_http_slice_filter_module);            
> +    if (r->background && r != r->main && r->main != r->parent) {               
> +        ctx = ngx_http_get_module_ctx(r->parent, ngx_http_slice_filter_module);
> +    }

Here you’re trying to get the parent request’s context to access the slice range.
But slice range is being constantly updated.  So there’s no guarantee that you get
the right slice range.

The right solution would be to pass the slice range to the background update
subrequest as an argument or a part of uri.  But that does not seem to be possible
within the current background update implementation. Probably there’s a way to save
and then access the right slice using njs.

>                                                                          
>                                                                                 
>      if (ctx == NULL) {                                                         
> -        if (r != r->main || r->headers_out.status) {                           
> +        if ((r != r->main && !r->background) || r->headers_out.status) {       
>              v->not_found = 1;                                                  
>              return NGX_OK;                                                     
>          }

Here you are creating a new ctx for the background update subrequest,
which suggests that you want to update the entire response rather that
only one slice.

> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel

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