Enable http2 Support for nginx with docker

[t-book]

HTTP2 the successor of HTTP 1.1 brings advantages in speed as it lifts the limitation of concurrent requests to infinite.

HTTP 1.1

Firefox 2:  2
Firefox 3+: 6
Opera 9.26: 4
Opera 12:   6
Safari 3:   4
Safari 5:   6
IE 7:       2
IE 8:       6
IE 10:      8
Chrome:     6

For a comparison of loading have a look here: https://imagekit.io/demo/http2-vs-http1?utm_source=blog&utm_medium=blog&utm_campaign=Blog

For further information about HTTP1.1 vs HTTP2 visit:

• https://css-tricks.com/http2-real-world-performance-test-analysis/#:~:text=HTTP%2F2%20is%20faster%20and,site%20loading%20time%20than%20HTTP1.
• https://imagekit.io/blog/http2-vs-http1-performance/

As Browsers will accept HTTP2 only with a secure transport protocol only changes to nginx.https.available.conf.envsubst are needed as shown here: https://docs.google.com/document/d/1fsFA1Zq1ZSYMETIFEEtquB9AlhNHNHuM3_ZSZhLK4gg/edit?usp=sharing

(The support of IPv6 is optional but could be an improvement as well)

[giohappy]

@t-book thanks for the heads up on this topic. I totally agree in pushing this forward.

[t-book]

thanks @giohappy . There is another thing regarding serving content. The static files are currently loaded over the same domain. With HTTP2 we will get rid of the Browser limitation of concurrent requests but still we transport the content over a 'cookie enabled domain'. This is an additional unneeded load. (That's why some projects use a subdomain or different domain for static content)

We could envisage using a CDN for serving static files. My choice is cdn.jsdelivr. All that is needed is that you define the source file in question as a github path:

Scheme https://cdn.jsdelivr.net/gh/@PROJECT-NAME/@REPOSITORY/PATH-TO-FILE For example: https://cdn.jsdelivr.net/gh/GeoNode/geonode/geonode/static/lib/css/assets.min.css

will load assets.min.css from Github master branch from the closest available server over HTTP2. In my tests, this leads again to a small advantage in speed.

However, there are some things to consider. We should respect the specific geonode version which would expose the branch again. https://cdn.jsdelivr.net/gh/GeoNode/[email protected]/geonode/static/lib/css/assets.min.css Exposing versions is something I would try to avoid wherever possible in production. (This includes https://master.demo.geonode.org/version.txt ). Unsure if for some users geoblocking could be an issue as well but this could be solved by some settings var ENABLE_CDN=False. For sure one needs to respect the CDN in privacy policy ...

Long story short, the use of a cdn for static content maybe something for the future ;)