Ah, thanks for that, I did not know about this. So it is not a bug. If anyone can, please, close the trac ticket I opened.<br><br>--<br>Sent from my phone.<br>Anton Luka Šijanec<br>https://šijanec.eu/<br>+386 64/176-345<br>anton@sijanec.eu (email, xmpp & sip)<br>https://šijanec.eu/pgp-key.txt<div class="quote" style="line-height: 1.5"><br><br>-------- Original Message --------<br>Subject: Re: bug: subrequest, addition_filter and not_modified<br>From: Maxim Dounin <mdounin@mdounin.ru><br>To: nginx-devel@nginx.org<br>CC: <br><br><br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br><br>On Sat, Oct 03, 2020 at 04:15:13PM +0200, Anton Luka Šijanec wrote:<br><br>> I have just stumbled upon a nginx bug. When using add_before_body and/or <br>> add_after_body commands from ngx_http_addition_filter_module, the server <br>> will respond with "304 Not Modified" even if the added file has changed.<br>> <br>> After investigation I figured out that this error could be applied to <br>> everything that uses ngx_http_subrequest to gather data. The request <br>> structure will remain with the same last_modified_time even if the <br>> subrequest contains data that was modified after this time. The solution <br>> to this problem would be to overwrite the request structure <br>> headers_out.last_modified_time with the last_modified_time in the <br>> structure, generated by ngx_http_subrequest, if it's in the future, but <br>> that would not be enough.<br><br>The usual approach is to clear the last modified time of the main <br>request in the filter which is expected to significantly modify <br>the response.  For example, this is what SSI module does:<br><br>        if (!slcf->last_modified) {<br>            ngx_http_clear_last_modified(r);<br>            ngx_http_clear_etag(r);<br><br>        } else {<br>            ngx_http_weak_etag(r);<br>        }<br><br>This is not the case for addition filter though, as it is <br>expected to be used for non-essential additions, and hence <br>only makes the response ETag weak, much like what SSI does <br>with "ssi_last_modified on;".<br><br>-- <br>Maxim Dounin<br>http://mdounin.ru/<br>_______________________________________________<br>nginx-devel mailing list<br>nginx-devel@nginx.org<br>http://mailman.nginx.org/mailman/listinfo/nginx-devel</blockquote></div>