CherryPy comes with its own web (HTTP) server. That is why CherryPy is self-contained and allows users to run a CherryPy application within minutes of getting the library.

The web server acts as the gateway to the application with the help of which all the requests and responses are kept in track.

To start the web server, a user must make the following call −

cherryPy.server.quickstart()

The internal engine of CherryPy is responsible for the following activities −

• Creation and management of request and response objects.
• Controlling and managing the CherryPy process.

CherryPy – Configuration

The framework comes with its own configuration system allowing you to parameterize the HTTP server. The settings for the configuration can be stored either in a text file with syntax close to the INI format or as a complete Python dictionary.

To configure the CherryPy server instance, the developer needs to use the global section of the settings.

global_conf = {
   ''global'': {
      ''server.socket_host'': ''localhost'',
      ''server.socket_port'': 8080,
   },
}

application_conf = {
   ''/style.css'': {
      ''tools.staticfile.on'': True,
      ''tools.staticfile.filename'': os.path.join(_curdir, ''style.css''),
   }
}

This could be represented in a file like this:
[global]
server.socket_host = "localhost"
server.socket_port = 8080
[/style.css]
tools.staticfile.on = True
tools.staticfile.filename = "/full/path/to.style.css"

HTTP Compliance

CherryPy has been evolving slowly but it includes the compilation of HTTP specifications with the support of HTTP/1.0 later transferring with the support of HTTP/1.1.

CherryPy is said to be conditionally compliant with HTTP/1.1 as it implements all the must and required levels but not all the should levels of the specification. Therefore, CherryPy supports the following features of HTTP/1.1 −

• If a client claims to support HTTP/1.1, it must send a header field in any request made with the specified protocol version. If it is not done, CherryPy will immediately stop the processing of the request.

• CherryPy generates a Date header field which is used in all configurations.

• CherryPy can handle response status code (100) with the support of clients.

• CherryPy”s built-in HTTP server supports persistent connections that are the default in HTTP/1.1, through the use of the Connection: Keep-Alive header.

• CherryPy handles correctly chunked requests and responses.

• CherryPy supports requests in two distinct ways − If-Modified-Since and If-Unmodified-Since headers and sends responses as per the requests accordingly.

• CherryPy allows any HTTP method.

• CherryPy handles the combinations of HTTP versions between the client and the setting set for the server.

Multithreaded Application Server

CherryPy is designed based on the multithreading concept. Every time a developer gets or sets a value into the CherryPy namespace, it is done in the multi-threaded environment.

Both cherrypy.request and cherrypy.response are thread-data containers, which imply that your application calls them independently by knowing which request is proxied through them at runtime.

Application servers using the threaded pattern are not highly regarded because the use of threads is seen as increasing the likelihood of problems due to synchronization requirements.

The other alternatives include −

Multi-process Pattern

Each request is handled by its own Python process. Here, performance and stability of the server can be considered as better.

Asynchronous Pattern

Here, accepting new connections and sending the data back to the client is done asynchronously from the request process. This technique is known for its efficiency.

URL Dispatching

The CherryPy community wants to be more flexible and that other solutions for dispatchers would be appreciated. CherryPy 3 provides other built-in dispatchers and offers a simple way to write and use your own dispatchers.

• Applications used to develop HTTP methods. (GET, POST, PUT, etc.)
• The one which defines the routes in the URL – Routes Dispatcher

HTTP Method Dispatcher

In some applications, URIs are independent of the action, which is to be performed by the server on the resource.

For example,http://xyz.com/album/delete/10

The URI contains the operation the client wishes to carry out.

By default, CherryPy dispatcher would map in the following way −

album.delete(12)

The above mentioned dispatcher is mentioned correctly, but can be made independent in the following way −

http://xyz.com/album/10

The user may wonder how the server dispatches the exact page. This information is carried by the HTTP request itself. When there is request from client to server, CherryPy looks the best suiting handler, the handler is representation of the resource targeted by the URI.

DELETE /album/12 HTTP/1.1

Routes Dispatcher

Here is a list of the parameters for the method required in dispatching −

• The name parameter is the unique name for the route to connect.

• The route is the pattern to match URIs.

• The controller is the instance containing page handlers.

• Using the Routes dispatcher connects a pattern that matches URIs and associates a specific page handler.

Example

Let us take an example to understand how it works −

import random
import string
import cherrypy

class StringMaker(object):
   @cherrypy.expose
   def index(self):
      return "Hello! How are you?"
   
   @cherrypy.expose
   def generate(self, length=9):
      return ''''.join(random.sample(string.hexdigits, int(length)))
		
if __name__ == ''__main__'':
   cherrypy.quickstart(StringMaker ())

Follow the steps given below to get the output of the above code −

Step 1 − Save the above mentioned file as tutRoutes.py.

Step 2 − Visit the following URL −

http://localhost:8080/generate?length=10

Step 3 − You will receive the following output −