bug: subrequest, addition_filter and not_modified

[Maxim Dounin]

Hello!

On Sat, Oct 03, 2020 at 04:15:13PM +0200, Anton Luka Šijanec wrote:

> I have just stumbled upon a nginx bug. When using add_before_body and/or 
> add_after_body commands from ngx_http_addition_filter_module, the server 
> will respond with "304 Not Modified" even if the added file has changed.
> 
> After investigation I figured out that this error could be applied to 
> everything that uses ngx_http_subrequest to gather data. The request 
> structure will remain with the same last_modified_time even if the 
> subrequest contains data that was modified after this time. The solution 
> to this problem would be to overwrite the request structure 
> headers_out.last_modified_time with the last_modified_time in the 
> structure, generated by ngx_http_subrequest, if it's in the future, but 
> that would not be enough.

The usual approach is to clear the last modified time of the main 
request in the filter which is expected to significantly modify 
the response.  For example, this is what SSI module does:

        if (!slcf->last_modified) {
            ngx_http_clear_last_modified(r);
            ngx_http_clear_etag(r);

        } else {
            ngx_http_weak_etag(r);
        }

This is not the case for addition filter though, as it is 
expected to be used for non-essential additions, and hence 
only makes the response ETag weak, much like what SSI does 
with "ssi_last_modified on;".

-- 
Maxim Dounin
http://mdounin.ru/