Setting Up a Front End HTTP Server

Set Up with lighttpd⚙️

lighttp is a safe, fast, compliant, and highly adaptable web server designed for high-performance situations. lighttpd makes better use of memory and CPU resources than other popular web servers.

The following example illustrates how to set up lighttpd as a front-end web server. You can accomplish the same thing with apache, but if you require virtual hosting or load balancing, lighttpd is a better alternative and much easier to set up.

The configuration should be defined in the /etc/lighttpd/lighttpd.conf file is shown below:

server.modules = (
      "mod_access",
      "mod_proxy",
      "mod_accesslog"
)

$HTTP["host"] =~ "www.myapp.com" {
    proxy.balance = "round-robin" proxy.server = ( "/" =>
        ( ( "host" => "127.0.0.1", "port" => 9000 ) ) )
}

$HTTP["host"] =~ "www.loadbalancedapp.com" {
    proxy.balance = "round-robin" proxy.server = ( "/" => (
          ( "host" => "127.0.0.1", "port" => 9001 ),
          ( "host" => "127.0.0.1", "port" => 9002 ) )
    )
}

Set Up with Nginx🔧

NGINX is a free and open-source web server that may be used for web serving, reverse proxying, caching, load balancing, video streaming, and other tasks. It began out as a web server designed for maximum performance and stability.

The following example demonstrates how to set up nginx as a front-end web server. You can perform the same thing with apache, but if you require virtual hosting or load balancing, nginx is a better alternative and much easier to set up.

The following upstream and server blocks should be defined in the /etc/nginx/nginx.conf file:

upstream playapp {
  server 127.0.0.1:9000;
}

server {
  listen 80;
  server_name www.domain.com;
  location / {
    proxy_pass http://playapp;
  }
}

Note: If you use Nginx version 1.2 or higher, chunked responses will not operate correctly.

Set Up with Apache⚙

The apache HTTP Server Project is an open-source HTTP server development and maintenance effort for current operating systems such as UNIX and windows. This project aims to develop a safe, efficient, and flexible server that provides HTTP services by current HTTP standards.

The following example illustrates a basic setup with an apache httpd server operating in front of a typical play configuration.

LoadModule proxy_module modules/mod_proxy.so
…
<VirtualHost *:80>
  ProxyPreserveHost On
  ServerName www.loadbalancedapp.com
  ProxyPass  /excluded !
  ProxyPass / http://127.0.0.1:9000/
  ProxyPassReverse / http://127.0.0.1:9000/
</VirtualHost>

Advanced Proxy Settings🧑🏻‍🔧

Request addresses are interpreted as coming from the HTTP server while utilising an HTTP frontal server. In a typical setup, when the play app and the proxy are operating on the same system, the play app will see requests originating from 127.0.0.1.

To indicate the proxied application where the request came from, proxy servers might add a special header to the request. Most web servers will add an X-Forwarded-For header to the request, with the remote client IP address as the first parameter. Play will trust the X-Forwarded-For header if the proxy server is operating on localhost and connected from 127.0.0.1.

On the other hand, the host header is unaffected; it will continue to be issued by the proxy. If you are utilising apache 2.x, you may add a directive such as:

ProxyPreserveHost on

The host header will be the client's original host request header. Combining these two strategies will make your app appear to be immediately exposed. If you do not want this play app to take up the entire root, add the following exclusion directive to the proxy configuration:

ProxyPass /excluded !

Apache as a Front Proxy👨🏻‍💻

We can use apache as a front proxy to allow a transparent application upgrade. The central concept is to run two instances of your web application in play and will enable the front-end proxy load to balance them. If one is not accessible, it will route all requests to the next available one.

Let's run the identical play app twice: once on port 9999 and once on port 9998.

start -Dhttp.port=9998
start -Dhttp.port=9999

Now, let's add a load balancer to our apache web server. Add the following settings to apache:

<VirtualHost mysuperwebapp.com:80>
  ServerName mysuperwebapp.com
  
  <Location /balancer-manager>
    SetHandler balancer-manager
    Order Deny,Allow
    Deny from all
    Allow from .mysuperwebapp.com
  </Location>
  
  <Proxy balancer://mycluster>
    BalancerMember http://localhost:9999
    BalancerMember http://localhost:9998 status=+H
  </Proxy>
  
  <Proxy *>
    Order Allow,Deny
    Allow From All
  </Proxy>
  
  ProxyPreserveHost On
  ProxyPass /balancer-manager !
  ProxyPass / balancer://mycluster/
  ProxyPassReverse / balancer://mycluster/
  
</VirtualHost>

The key component is balancer:/mycluster. This specifies the presence of a load balancer. The +H option indicates that the second play application is in the background. You may, however, direct it to load balance.

You may also use apache to verify the status of your cluster. To examine the current state of your clusters, navigate to /balancer-manager. You do not have to manage sessions between the two clusters because play is stateless. You may quickly scale up to more than two play instances. It would be best if you used mod_proxy_wstunnel, which was introduced in apache 2.4, to use WebSockets.

Note: ProxyPassReverse may improperly rewrite headers by appending an additional / to the URIs. Thus, you may want to use the following workaround:

ProxyPassReverse / http://localhost:9999
ProxyPassReverse / http://localhost:9998

Configuring Trusted Proxies👩‍💻

Play supports several forwarded headers that proxies employ to specify the incoming IP address and protocol of requests. This setting is used by play to determine the correct value for the remoteAddress and secure fields of the RequestHeader.

An HTTP client, whether a browser or another client, may quickly fabricate forwarded headers, faking the IP address and protocol that Play reports; as a result, Play needs to know which proxies can be trusted. Play allows you to create a list of trusted proxies. It will evaluate the arriving forwarded headers to ensure they are trustworthy, using the first untrusted IP address it discovers as the reported user remote address (or the last IP address if all proxies are trusted.)

You may configure the list of trusted proxies by configuring play.http.forwarded.trustedProxies. This function accepts a list of IP addresses or CIDR subnet ranges. IPv4 and IPv6 are both supported. As an example:

play.http.forwarded.trustedProxies=["192.168.0.0/24", "::1", "127.0.0.1"]

This indicates that all IP addresses beginning with 192.168.0 and IPv6 and IPv4 loopback addresses are trusted. Play will only trust the loopback address, which is ::1 and 127.0.0.1 by default.

Trusting All Proxies✔️

Many cloud providers, most notably AWS, provide no guarantees about the IP addresses used by their load balancer proxies. As a result, trusting all IP addresses is the only option to implement forwarded headers with these services. This may be accomplished by specifying the trusted proxies as follows:

play.http.forwarded.trustedProxies=["0.0.0.0/0", "::/0"]

Forwarded Header Version⏩

Play recognises two types of sent headers:

• the legacy method with X-Forwarded headers
• the RFC 7239 with Forwarded headers

This is set via play.http.forwarded.version, with valid values of x-forwarded or rfc7239. The default setting is x-forwarded.

To establish the right remote address and protocol for the request, x-forwarded employs the de facto standard X-Forwarded-For and X-Forwarded-Proto headers. These headers are widely used, but they have some severe limitations. For example, suppose you have multiple proxies, and only one adds the X-Forwarded-Proto header. In that case, it's impossible to determine which proxy added it and thus whether the client's request was made using https or http. rfc7239 uses the new Forwarded header standard, which overcomes many of the limitations of the X-Forwarded-* headers.

Frequently Asked Questions

Define the Play framework.

Play is based on a stateless, lightweight, web-friendly architecture. Play is built on Akka. It has minimal resource consumption. It is a developer-friendly framework and very versatile. Most of the Java libraries are also supported in play. 

Define lighttpd.

lighttp is a safe, fast, compliant, and highly adaptable web server designed for high-performance situations. lighttpd makes better use of memory and CPU resources than other popular web servers.

Describe nginx.

NGINX is a free and open-source web server that may be used for web serving, reverse proxying, caching, load balancing, video streaming, and other tasks. It began out as a web server designed for maximum performance and stability.

Play uses which code in level messages?

In level messages, Play employs ANSI colour codes by default.

What is a JVM application?

The JVM provides a portable execution environment for java-based applications while managing system memory.

Conclusion

In this article, we have extensively discussed setting up a front-end HTTP server. 

Do you not feel eager to read/explore additional information on the subject of the Play framework after reading about setting up a front-end HTTP server? See the Coordinated Shutdown, Configuring Netty Server Backend, Guidelines for Writing Play Documentation, and 15 Best Java frameworks to use in 2022-Coding Ninjas.

Recommended Readings:

• Apache Server

 

Refer to our guided paths on Coding Ninjas Studio to learn more about DSA, Competitive Programming, JavaScript, System Design, etc. Enrol in our courses and refer to the mock test and problems available. Take a look at the interview experiences and interview bundle for placement preparations.

Do upvote our blog to help other ninjas grow. 

Happy Learning Ninja! 🥷