Hello!

On Wed, Jul 16, 2014 at 8:54 AM, Maxim Dounin wrote:
> The same applies to r->headers_out.last_modified_time
> modifications in your module - what previously worked in your
> module was a hack, and there is no surprise it no longer works
> after changes.

IMHO, the ngx_http_upstream_module mechanism should be flexible enough
to do something like this. This is just a requirement that is so
simple.

> - Implement appropriate flag in upstream (or upstram
> configuration) to make it possible to activate not modified
> filter for responses which doesn't use cache.
>
> - Emulate 304 responses by the module itself.
>
> The latter is obviously easier from nginx core point of view. :)
> Also, it should be compatible with all nginx versions.
>

I'd vote for the first option and I hope you guys will find some time
to implement that in the nginx core.

The second approach means duplicating most of the logic in
ngx_http_not_modified_filter_module.c, which is not satisfying at all
from 3rd-party module developers' perspective (that is, my
perspective). It might be satisfying to the nginx core developers
though ;)

One strength of the nginx core is that most of the time the 3rd-party
module developers can find our way when doing something unplanned by
the original authors of the core. You may call it a hack or something
as you like but I consider it as a strength. Otherwise the nginx world
is just so boring and limited and no fun. Anyway the nginx core uses
so-called "hacks" here and there over the years so it is shameless
(and yeah, whether a thing should be called a "hack" is totally
subjective). Just my 2 cents.

Best regards,
-agentzh

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