Seven Things to Like About Appweb

appweb Embedthis Appweb™ is known as the fastest, little embedded web server, and Appweb 4 is a major upgrade to this little powerhouse. If you are using Appweb 3 or 2, Appweb 4 has some compelling reasons to upgrade. Here I list the top seven things I really like about Appweb 4.

1. Appweb is fast — really fast

The Nginx enterprise web server defined a new level of performance and supplanted Apache in many sites. But embedded web servers typically remain much slower than these enterprise speed daemons. While having gigabytes of available memory can certainly help web server speed, it is more important to use the right architecture and internal design. Appweb uses these same best practices but adapts them to the embedded world to achieve similar speeds to that of nginx.

Like Nginx, Appweb uses a non-blocking, event-based design to service requests asynchronously without requiring a dedicated process or thread per client request. Appweb uses events to service requests when they have activity that needs processing. So each worker thread is shared over many requests. This ensures fast response while consuming very little resources.

Appweb couples this event-based core with an efficient request pipeline. The pipeline is comprised of processing stages that apply filters to the incoming and outgoing data. These filters chunk, range, upload and cache requests. To save memory, pipeline stages transfer data in packets without copying. The packets efficiently carry packet headers or trailers so that data can be wrapped without copying. This is essential for efficient HTTP chunking.


The request pipeline communicates with the network and uses the most efficient O/O primitives available on the platform. Appweb supports vectored socket writes, sendfile and fast O/S event mechanisms like kqueue and epoll. This architecture gives an incredibly fast, but still very compact web server.

What does this mean for an embedded system? It means that Appweb can serve your content and use very little CPU resource to do it. This leaves the CPU to do its primary job for the embedded device.

2. Integrated Caching

The bane of dynamic web sites is that pages need to be generated each time a client requests them. For embedded applications where many, if not most, pages are dynamically generated, this can really slow performance. If a response could be saved and cached, subsequent requests could be served much more quickly — often one or two orders of magnitude more quickly. If the client can accept a "reasonably" current view of the system, then a cached page may suffice. Alternatively, the device can pre-generate a response and save to the cache before the client requests the page. This effectively shifts the generation delay so the client never sees it.

Appweb addresses this need with a highly configurable, integrated caching mechanism. The Appweb cache is delivered as an Appweb pipeline stage that can cache any content the client may request. The Appweb cache filters incoming requests and serves outgoing responses. If the cache contains a suitably current response, it can be served directly from the cache. If not, outgoing response data can be transparently cached for future requests.

Appweb caching is controlled on a per route (URL) basis. This means you can decide which parts of the application should be cached and for how long. In fact, the entire caching policy can be easily configured and controlled by Appweb configuration directives.

For example: this appweb.conf directive will cache responses for all URIs that begin with /scores/ for one hour on the server.

Cache server=1hr /scores/

If you are using Embedded Server Pages, the C-Language web framework, you can expire cached responses or manually seed the cache with pre-made responses. See the httpUpdateCache API for details.

You can have Appweb transparently cache the response at the server or configure the route to cache at the client side. For example:

Cache client=1hr /scores/

Responses can be cached for any period of time and browser refreshes correctly bypass the cached data. Caching can be configured to uniquely cache responses with different request parameters.

Cache unique /scores/

You can limit the total size of the cache with the LimitCache directive and limit the maximum size of a a response by the LimitCacheItem directive.

Cache           1hour   / define a default cache period
LimitCache      1MB     / Dedicate 1MB to the cache store
LimitCacheItem  100K    / Limit the biggest cached item

For more information on caching, read the Appweb Response Caching guide.

3. Routing Engine

Routing Engine In modern web applications, you need to partition different parts of the application and apply different processing to the various parts. You may want to restrict access only to authenticated users. You may want to cache the output of some slowly changing, yet dynamic data. Or you may want to use RESTful URIs where URIs mean different things depending on the HTTP method verb. There are many reasons, but the web server must provide a way to differently handle the processing of various URIs. Enter the Appweb routing engine.

Appweb has an efficient and flexible routing engine that allows URI groups to be processed (routed) differently. Routes are created in the appweb.conf configuration file using the Route directive to define a set of processing instructions that apply to a URI group. The Route directive specifies a URI prefix for which eligible requests must match. This may be a simple string or a Regular Expression. You can create any number of routes and they are processed in the order in which they are defined in the appweb.conf file. Routes can be also nested so that inner routes inherit the definitions of outer route blocks.

For example, a typical route block:

<Route /private>
    Documents "${DOCUMENT_ROOT}/private"
    AuthType basic  # Use basic authentication
    Require secure              # Must be accessed over SSL
    Require ability edit        # Authenticated users must have the edit ability
    LimitRequestBody 100k       # Only requests less than 100K are accepted
    RequestTimeout 10secs       # Request must complete in < 10 seconds
    RequestParseTimeout 2secs   # Denial-of-service protection

Most Appweb directives apply to the enclosing route. So a route can exactly specify its configuration. Some of the useful directives for inside a route block are:

  • SetHandler — request handler to serve the request (CGI, ESP, EJS, PHP, ...)
  • Documents — the directory from which to serve content
  • AuthType — authentication protocol: (basic, digest or web form)
  • Cache — how to cache the responses
  • Redirect — response redirecting
  • AddLanguageDir — multi-language content
  • Compress — serve compressed responses
  • Methods — allowable request methods
  • Require — Required user credentials, role or abilities
  • Limit* — Security sandbox limits
  • SSLCertificateFile — SSL configuration

For more information on routing, read the Appweb Request Routing guide. and the Appweb Configuration Directives.

4. Security sandbox

I'm going to make some broad, sweeping generalizations that apply to many if not most embedded devices. Yes, I know there are exceptions. But please bear with me, as these generalizations contain a truth about how embedded is very different to enterprise, and why a security sandbox works especially well for embedded.

Compared to an enterprise server, an embedded web server:

  • is secondary to the primary purpose of the device or application in which it is embedded
  • has a defined, and more uniform client load
  • is efficient in serving fewer rather than many clients

If the characteristic client load for an embedded web server is more uniform and designed to efficiently serve fewer clients, then a security sandbox can be defined to tightly describe acceptable and non-acceptable client use. Requests that are outside this acceptable client request profile, can be denied. This greatly helps to thwart denial of service and other security attacks.

The Appweb security sandbox defines what clients and requests are acceptable. The Sandbox is configured by appweb.conf directives. Here are some of the sandbox directives:

Because the sandbox limits apply on a per-route basis, the various parts of the web application can be differently sandboxed. For more information on security, read the Appweb Security Considerations guide.

5. Authentication Framework

Half-baked authentication is not much better than no authentication at all. Attackers will exploit the weakest link, so it is imperative that embedded systems are thoroughly secured and user accesses are correctly authenticated. However, this requires an end-to-end login and authentication scheme. Typically, developers have to cobble this together themselves. Appweb provides an integrated and complete solution that includes:

  • User login and logout mechanism
  • Secure password transmission
  • Flexible password stores
  • Authenticating the user credentials
  • Controlling access to resources by specific users or user groups

Appweb provides three authentication protocols: basic, digest and web-form. If using a web-form to enter login credentials, Appweb will automatically transition to SSL to ensure the password is transmitted securely. Passwords can be encrypted and stored in a flat file or using the native operating system password mechanisms.

Once authenticated, the user is authorized with a set of "abilities". These are configured for each user via the Appweb role-based authorization scheme. Each route (set of URIs) can be configured to require certain abilities before access is granted to the user. The Require directive can specify a set of required abilities.

The directive below configures authentication using web-form authentication. It uses the login.esp page for the user to enter their username and password. The /auth/login URI receives and validates the user's login credentials. If acceptable, an authenticate session is created and a cookie returned in the response. The /auth/logout URI is bound to the Appweb service to log the user out. Lastly, once logged in, the user is redirected to the home web page.

AuthType form https:///auth/login.esp https:///auth/login /auth/logout /

The Appweb authentication framework is comprehensive and saves developers from having to piece together a solution from bit-parts. For more details, read Authentication in the Appweb documentation.

6. Embedded Server Pages

Perhaps the best part of Appweb 4, is the ESP web framework. This is a full MVC web framework that makes it dramatically easier to create blazing fast, dynamic web applications.

ESP has learned from other leading web frameworks like the Ruby framework Rails and the Javascript web framework Node. ESP is a C-Language web framework, but unlike normal C coding, the ESP framework supports embedding C code inside template web pages. Better, it supports the dynamic and transparent recompilation and reloading of web pages when they are modified. It also detects and automatically recompiles modified ESP controllers (written in C). This makes ESP behave like a scripted web framework.

But what about memory allocation? And what about memory leaks? Surely a C-language framework is not suited for this, I hear you say. To address this valid concern, ESP uses a garbage collector to automatically free memory when a request has been completed. This means web pages do not need to worry about releasing memory or memory leaks.

The ESP framework provides an application generator, web page template engine, a Model-View-Controller framework, a library of HTML controls and an extensive API to take the tedium out of creating web applications. Via this framework, ESP greatly reduces the lines of code you need to write for web apps.


ESP applications are typically defined in a consistent set of directories:

  • cache — for cached pre-compiled ESP controllers and pages
  • client — for client-side web page content, images, stylesheets etc.
  • controllers — for ESP controller functions
  • layouts — for master web page layouts
  • db — for databases and database migrations

To make it easy to get started quickly, ESP includes an application generate. To create a new app:

mkdir blog
cd blog
esp install esp-html-mvc

To create a MVC scaffold for entering blog posts:

esp generate scaffold post title:string body:text

ESP has so much to offer, that it will require a separate blog post. But it is my favorite part of Appweb. For more information, see ESP.

7. WebSockets

The Appweb WebSockets support brings real-time full-duplex communications with clients. Importantly, this permits efficient server initiated communications. The Appweb WebSockets module is a complete server and client WebSockets implementation supporting the latest WebSockets specification. Appweb applies sandbox limits to WebSockets connections, so that long-running WebSocket requests can be used safely. I'll say more about this in a future post.

Things that did not make the top 7

There are often things that almost make the cut, but don't quite get into the top "Top Seven". One of these deserves an honorable mention.

Building with MakeMe

Appweb has eliminated the old make+autoconf build scheme and uses the MakeMe, tool. This tool handles configuration, building, cross compilation and generation of IDE projects. All simply and painlessly. Goodbye make!

Try It

To try Appweb 4, download from

About Appweb

Embedthis Appwebâ„¢ is the fastest, little embedded web server. It is unmatched in efficiency and serves pages fast at native speed using minimal memory. Appweb uses an event-driven, non-blocking core to serve multiple requests using minimal resources. With integrated caching and the Embedded Server Pages C-Language web framework, Appweb is exceptionally fast. Without compromising performance, Appweb has extensive security controls and a rigorous security sandbox to protect the server and mitigate denial-of-service attacks. As one of the most widely deployed embedded web servers, Appweb is used in networking equipment, telephony, mobile devices, industrial control, and consumer and office equipment as well in high-performance web services. Appweb provides both Open-Source and commercial licenses and comes with full source code.

© Embedthis Software, 2003-2015. All rights reserved. Privacy Policy and Terms of Use.   Generated on Jun 2, 2016.