dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

Hi Bob,

thanks for working on this. The config looks good.

Have you confirmed that chrome and firefox will do (expiry) caching of
static content without validating with the server over SSL?

Morten, I seem to recall that the smartphone mobile module needs to know
the protocol on SSL to function properly, is that right? If so we need:

proxy_set_header  X-Forwarded-Proto  https;


regards,

Lars




On Fri, Mar 29, 2013 at 5:27 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:

> On 29 March 2013 15:16, Jason Pickering <jason.p.pickering@xxxxxxxxx>
> wrote:
> > I think this is a good and simple starting point. The only issue I see
> for
> > this is another situation, where mutliple DHIS2 instances are running on
> the
> > same machine, but under a different virtual host. This is simple enough
> with
> > the "server_name" directive, so we might need to at least document this.
> Not
> > exactly sure how common this is, but might be good to include it anyway.
>
> Yes I can see this would be a different way of "fronting".  I am going
> to concentrate on one approach for now where the webapp is mapped into
> the url of a single host, but maybe we could consider scripting the
> virtualhost setup as well in the future.
>
> >
> > Regards,
> > Jason
> >
> >
> >
> > On Thu, Mar 28, 2013 at 7:15 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx>
> wrote:
> >>
> >> I've run a few experiments with nginx and caching, verified with
> tcpdump.
> >>
> >> Attached is my suggestion for an nginx conf file dealing with multiple
> >> tomcat backends.
> >>
> >> A few things to note:
> >> 1.  this is not a full nginx.conf, but rather /etc/nginx/conf.d/dhis2
> >> as you would find when installing nginx from deb (which I am going to
> >> recommend)
> >> 2.  I've done the proxy pass configs as one-liners which should make
> >> easy for scriptable editing with sed
> >> 3.  after lots of fiddling with the static content business I have
> >> just dropped it for now.  What I have found and confirmed (at least
> >> with chrome) is that chrome is caching this content anyway so there is
> >> only very marginal utility in getting it served by nginx directly from
> >> the file system.  It will only be required occasionally.  The nginx
> >> cache doesn't work quite like the apache one in that this stuff is not
> >> automatically being cached by the proxy.  If it did then this would
> >> far and away be the simplest way to get served directly off the
> >> filesystem.  I guess in order to make this happen we have to set the
> >> Cache-Control headers with interceptors from within the webapp.  Which
> >> I think this is the right way to go about it anyway.  Using the proxy
> >> to fiddle with cache-control headers feels wrong.   Either way,
> >> because of the browser caching behaviour its actually a pretty small
> >> optimisation so I'm happy to lose it for now.
> >>
> >> Any comments on the conf file?
> >>
> >> Bob
> >>
> >> PS.  contrary to popular opinion I think the apache config is actually
> >> much more straightforward, but for the moment it looks like nginx is
> >> clearly superior on memory usage which I think is our primary concern
> >> in most cases.
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~dhis2-devs
> >> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~dhis2-devs
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>