Features

    It starts with a request, which is routed to a specific handler, processed by our application logic, and finally responded to.

    Many applications require common functionality that is out of scope of the application logic. This could be things like serialization and content encoding, compression, headers, cookie support, etc. All of these are provided in Ktor by means of what we call Features.

    If we look at the previous pipeline diagram, Features sit between the request/response and the application logic:

    Feature pipeline

    • It is routed to the correct handler via the routing mechanism

    • before being handed off to the handler, it goes through one or more Features

    • the handler (application logic) handles the request

    Features have been designed in a way to offer maximum flexibility, and allow them to be present in any segment of the request/response pipeline. In fact, what we’ve been calling until now, is nothing more than a Feature.

    Features are generally configured during the initialization phase of the server using the install function which takes a Feature as a parameter:

    In addition to intercepting requests and responses, Features can have an option configuration section which is configured during this step.

    For instance, when installing we can set certain parameters such as where we want Cookies to be stored, or their name:

    1. install(Sessions) {
    3. }

    By default, Ktor does not activate any Feature, and it’s up to us as developers to install the functionality our application need.

    Ktor does however provide a variety of Features that ship out of the box. We can see a complete list of these either on the Project Generator Site or in the . In addition we can also create our own custom Features