bug: subrequest, addition_filter and not_modified
Anton Luka Šijanec
anton at sijanec.eu
Sat Oct 3 14:15:13 UTC 2020
Hello!
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 problem is that ngx_http_subrequest does not populate the request
struct, specified as it's fourth argument, with
headers_out.last_modified_time, it stays at -1, but that wouldn't help
very much in this particular case.
Even setting the headers_out.last_modified_time to -1 in
addition_filter_module would not work and would not fix the issue,
because the filter modules do not execute before not_modified module
(nginx/auto/modules:142).
Well, at last resort, the not_modified module could load configuration
of addition_filter module and, if addition is to be done, return to the
next module. But that would not work either; the not_modified module
source is included before the addition_filter so it's module struct and
relying configurations are not available at the time of compilation.
Proof of bug: Run nginx with attached nginx.conf and create files
/tmp/add.html and /tmp/index.html with some content. Load
http://localhost:8080/ in a modern Firefox browser. Then change the file
/tmp/add.html and nginx will proceed to report "304 Not Modified" and
your browser's copy will after page refresh remain with the old
/tmp/add.html file added at the beginning of the response.
Regards!
I submitted the same text as a ticket:
https://trac.nginx.org/nginx/ticket/2055
--
Anton Luka Šijanec
https://šijanec.eu/
+38 6 64/176-345
anton at sijanec.eu (mail, xmpp & sip)
https://šijanec.eu/pgp-key.txt?F4C3E3A4DFB7254397A9F993E76135F49802CD14
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: nginx.conf
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20201003/9a645e2d/attachment.ksh>
More information about the nginx-devel
mailing list