BT

Nginx Plus R8 Brings Hardened HTTP/2 and Persistent Re-configuration API

| by Hrishikesh Barua Follow 14 Followers on Feb 09, 2016. Estimated reading time: 2 minutes |

Nginx announced Release 8 of the commercial version of their multi-protocol open source proxy server. The release includes HTTP/2 support, an API that persists configuration changes made at runtime and a preview implementation for integrating applications with OAuth providers like Google and Facebook.

The HTTP/2 protocol was finalized and published as an RFC in May 2015. Since then, various webservers like Apache and Jetty have added support for it. According to the article announcing the release, Nginx had added support for HTTP/2 in their previous release and the current release has a hardened implementation. InfoQ reached out to Nginx for more details about any publicly available performance benchmark results but did not receive an answer until the date of publication.

Nginx stores its configuration in configuration files, including configuration for upstream server groups. An upstream server group consists of one or more servers that are used as backend nodes when Nginx is running as a load balancer. In environments where the number of backend nodes needs to scale up and down dynamically in response to the traffic, this API enables the addition and removal of nodes from the load balancer on the fly. In addition to this kind of autoscaling, the article also notes that it’s useful in microservices architectures.

Addition or removal of backend nodes can also be done via a HTTP API. Until this release, changes made via the API were lost if Nginx were reloaded or restarted. Such changes are now persisted in the configuration files.

The OAuth open authorization standard is often used as a way for users to login to applications using their existing Google, Facebook, Twitter and similar ids. Application developers integrate OAuth as an easy way to add authorization to their apps. The OAuth flow using a third party service like Google involves taking the user to the site (Google in this case) and obtaining an access token after successful authentication to so that the application can use the user’s information from Google.

In this release Nginx has provided a preview of their implementation which attempts to offload the OAuth processing from the application to the load balancer. It can be done by including an additional Auth Request module at build time. This module adds a directive called auth_request in the configuration file. This module forwards authentication requests to a service called oauth-daemon which converts OAuth access tokens to HTTP headers. These headers are then sent to the application.

Other features in this release include scalable caching for large video files and the ability to specify multiple ports for health checks.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT