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
