Do you think IIT Guwahati certified course can help you in your career?
No
Introduction
In this article, we will understand the Akka HTTP Server Backend. Play implements HTTP requests and responses across the network using Akka Streams and the Akka HTTP server backend.
Play by default uses the Akka HTTP server backend. Akka HTTP supports the entire HTTP server stack with full HTTPS support and HTTP/2 support.
Play Akka HTTP Server
Play enables HTTP queries and responses using Akka Streams via the network using the Akka HTTP server backend. Play's server backend employs the low-level server API to handle the HTTP request.
It converts an Akka HttpRequest into a Play HTTP request. Play uses the strength and dependability of Akka-HTTP when processing requests while taking all of the routing and application logic surrounding the server backend.
Configuring the Akka HTTP Server Backend
Play's default server backend is the Akka HTTP server. The server backend is config with Typesafe config.
# Copyright (C) Lightbend Inc. <https://www.lightbend.com> *@
# Configuration for Play's AkkaHttpServer
play {
server {
@* The server provider class name *@
provider = "play.core.server.AkkaHttpServerProvider"
akka {
@* When attaching to the listening socket, the bindTimeout specifies how long to wait.*@
bindTimeout = 5 seconds
@*how much time elapses until a request times
out? To turn off the timeout, set the value to zero or "infinite.".*@
requestTimeout = infinite"
@*Timeout following which all requests and connections will be forcibly closed when the server is turned off. The Coordinated Shutdown service-unbind phase timeout will be used by default. Duration must be a value.
For example:
play.server.akka.terminationTimeout = 10 seconds*@
terminationTimeout = null
@* Automatic HEAD request handling is either enabled or disabled. The server sends HEAD requests to the application as GET requests and automatically removes all message bodies from incoming responses if this setting is enabled. The server will never provide message bodies as replies to HEAD requests, even when this setting is disabled.*@
transparent-head-requests=off
@* In case you have missed the setting, it will accept only the request that has a non empty host header else. It will generate the 400 Bad request error.
To force the server to accept such requests in the absence of a 'Host' header or the event that it is empty, set to a non-empty value. This setting only applies to HTTP/1.1 requests with an empty Host header as well as HTTP/1.0 requests therefore take note that the server will never accept HTTP/1.1 requests without a 'Host' header *@
@* Examples: `www.nova.io` or `example.com:8080.`*@
default-host-header = ""
@*The 'Server' header's default value, which is produced if a response does not contain an explicit 'Server' header.
There will be no "Server" header rendered if this value is null and no title was included in the request.
server-header = null
server-header = ${?play.server.server-header}
@* sets the processing mode when the response's header value contains illegal characters. *@
@*Supported mode:
`error`: issue a *@
ParsingException and stop processing in default mode
@* `warn`: the response header value's invalid characters should be ignored, and a warning message should be logged *@
illegal-response-header-value-processing-mode = warn in the header value
@* Sets whether a Tls-Session-Info header should be included in parsed messages sent via Tls transports. For additional details on how this functions, go to Akka HTTP's "akka.http.server.parsing.tls-session-info-header" section. *@
tls-session-info-header = on
}
}
}
These configurations are particularly for Akka HTTP server backend. There are some general configurations that are also available.
@* Copyright (C) Lightbend Inc. <https://www.lightbend.com> *@
play {
server {
@* the primary location of the Play server instance. By giving a route to the Play server as its first parameter, this value can be set.
launcher script. See *@`
ServerConfig.loadConfiguration`.
dir = ${?user.dir}
@* HTTP configuration *@
http {
@*The HTTP port of the server. Use a value of "disabled" if the server
# shouldn't bind an HTTP port.*@
port = 9000
port = ${?PLAY_HTTP_PORT}
port = ${?http.port}
@* The interface address to bind to. *@
address = "0.0.0.0"
address = ${?PLAY_HTTP_ADDRESS}
address = ${?http.address}
@*An open connection's inactive timeout, after which it will be closed.
Set to null or "infinite" could turn off the timeout. Although doing so is not advised, timeouts are crucial safeguards against malicious attacks and programming errors on your servers.*@
idleTimeout = 75 seconds
}
@* HTTPS configuration *@
https {
@* The HTTPS port of the server. *@
port = ${?PLAY_HTTPS_PORT}
port = ${?https.port}
@* The interface address to bind to *@
address = "0.0.0.0"
address = ${?PLAY_HTTPS_ADDRESS}
address = ${?https.address}
@*An accessible connection's inactive timeout, after which it will be closed.
Set to null or "infinite" disable the timeout, but keep in mind that this is not recommended as timeouts are crucial safeguards against malicious attacks or programming errors on your servers.s. *@
idleTimeout = ${play.server.http.idleTimeout}
@* The SSL engine provider *@
engineProvider = "play.core.server.ssl.DefaultSSLEngineProvider"
engineProvider = ${?play.http.sslengineprovider}
@* Configuration of the HTTPS keystore, as used by the default SSL engine provider *@
keyStore {
@* The path to the keystore *@
path = ${?https.keyStore}
@* The type of the Keystore *@
type = "JKS"
type = ${?https.keyStoreType}
@* The password for the Keystore *@
password = ""
password = ${?https.keyStorePassword}
@*If there is no algorithm that has been set, it will by default use the platform algorithm. *@
algorithm = ${?https.keyStoreAlgorithm}
}
@* Configuring the HTTPS truststore *@
trustStore {
# Do not perform client-side certifications. If genuine no need for CA authentication.
noCaVerification = false
}
@* Whether to use client auth mode in JSSE is up to you. In other words, the server will ask for a client certificate. But won't fail if one isn't provided. *@
wantClientAuth = false
@* Whether or not to use client auth mode with JSSE. This indicates that the server will request a client certificate, attempt to verify it, fail, and end the session. *@
@* if one isn't provided. *@
needClientAuth = false
}
@* The location of the process ID file the server creates when it is running.
If set to "/dev/null," then no pid file will be created. *@
pidfile.path = ${play.server.dir}/RUNNING_PID
pidfile.path = ${?pidfile.path}
websocket {
@* Maximum frame payload length permitted. Adding your application's value here *@
@* lengthy data frame requirements could lessen denial of service threats. *@
frame.maxLength = 64k
frame.maxLength = ${?websocket.frame.maxLength}
}
debug {
@* This will add debug information to attribute to each request if it is set to true. This setting parameter is disregarded, and the debug # information is permanently attached if the application *@
@* cannot be loaded (for example, because of a build error in development mode). *@
@* Note: This setting is not a component of Play's this public API is flexible and subject to change, without the typical # deprecation cycle *@
addDebugInfoToRequests = false
}
@* The HTTP headers' maximum length. The most frequent result of this is a limitation on cookie duration, including cookie quantity and cookie value size. *@
max-header-size = 8k
@* If a request includes a Content-Length header, it will be compared to this limit. The request will not be processed further, and the error handler will be invoked with the HTTP status code 413, "Entity too large," if the value of a specific Content-Length header exceeds this configured value. *@
@* If it is set to infinite or if there is no Content-Length header, then there will be no check at all, and the request processing will continue as normal. We set this restriction to infinite as Play employs the idea of a "BodyParser" to enforce it. *@
max-content-length = infinite
}
editor = ${?PLAY_EDITOR}
}
If the "AkkaHttp2Support" plugin is activated, there is additionally a separate configuration file for the HTTP/2 support in Akka HTTP:
Play's AkkaHttpServer class can be extended with your own if you require direct access to the ServerSettings and ParserSettings objects of Akka HTTP. There are a number of protected methods in the AkkaHttpServer class that can be modified to alter how Play configures its Akka HTTP backend.
Writing your own server class is an added advantage that can be easily done through general configurations.
The code below has some changes in the default Akka HTTP settings. A class called ServerProvider follows the server class and serves as a factory for the customized server.
package server
import java.util.Random
import play.core.server.AkkaHttpServer
import play.core.server.AkkaHttpServerProvider
import play.core.server.ServerProvider
import akka.http.scaladsl.ConnectionContext
import akka.http.scaladsl.model.HttpMethod
import akka.http.scaladsl.settings.ParserSettings
import akka.http.scaladsl.settings.ServerSettings
@* A customised, highly configured Akka HTTP server. *@
class CustomAkkaHttpServer(context: AkkaHttpServer.Context) extends AkkaHttpServer(context) {
protected override def createParserSettings(): ParserSettings = {
val defaultSettings: ParserSettings =
super.createParserSettings()
defaultSettings.withCustomMethods(HttpMethod.custom("TICKLE"))
}
protected override def createServerSettings(
port: Int,
connectionContext: ConnectionContext,
secure: Boolean
): ServerSettings = {
val defaultSettings: ServerSettings =
super.createServerSettings(port, connectionContext, secure)
defaultSettings.withWebsocketRandomFactory(() => new Random())
}
}
@* A factory that instantiates a CustomAkkaHttpServer. *@
class CustomAkkaHttpServerProvider extends ServerProvider {
def createServer(context: ServerProvider.Context) = {
val serverContext = AkkaHttpServer.Context.fromServerProviderContext(context)
new CustomAkkaHttpServer(serverContext)
}
Since you have changed the default settings, you need to inform play about the same. Now for this, You must specify the serverProvider class's entire name in the play.server.provider configuration option.
Adding the following parameters, for instance, to your application's build.sbt. Application.conf instructs Play to use your new server for both the sbt run process and the deployment of your application.
Play is a free, open-source web application framework that follows the MVC architecture. MVC stands for model, view, and controller.
What is Akka HTTP Server?
Akka HTTP is a series that helps you to implement the server-side and the client-side HTTP stack.
What is Akka stream?
It is developed over Akka actors, which helps to make the processing easy and easily accessible.
Is Akka a programming language?
No, Akka is not a programming language, but it does support multiple programming models for concurrency.
Which server does Play use initially?
Play has two server backend configurations, but by default, play uses Akka HTTP server backend.
Conclusion
In this article, we have deeply understood how Play uses the Akka HTTP server backend. We have further seen how this configuration is used in the server. We further look into the changes that can be made to change the default settings. We have looked into the direct configuration as well.
You may further learn more about Play and its configuration by visiting the links mentioned.