WSGI Server

This is the most important pulsar application. The server is a specialized socket server for web applications conforming with the python web server gateway interface (WSGI 1.0.1). The server can be used in conjunction with several web frameworks as well as pulsar wsgi application handlers, pulsar router, the pulsar RPC middleware and the websocket middleware.


Pulsar wsgi server is production ready designed to easily handle fast, scalable http applications. As all pulsar applications, it uses an event-driven, non-blocking I/O model that makes it lightweight and efficient. In addition, its multiprocessing capabilities allow to handle the c10k problem with ease.

An example of a web server written with the wsgi module which responds with Hello World! for every request:

from pulsar.apps import wsgi

def hello(environ, start_response):
    data = b"Hello World!"
    response_headers = [('Content-type','text/plain'),
                        ('Content-Length', str(len(data)))]
    start_response("200 OK", response_headers)
    return [data]

if __name__ == '__main__':

For more information regarding WSGI check the pep3333 specification. To run the application:


For available run options:

python --help

WSGI Server

class pulsar.apps.wsgi.WSGIServer(callable=None, load_config=True, **params)[source]

A WSGI SocketServer.

HTTP Protocol Consumer

class pulsar.apps.wsgi.server.HttpServerResponse(wsgi_callable, cfg, server_software=None, loop=None)[source]

Server side WSGI ProtocolConsumer.


The wsgi callable handling requests.


Implements data_received() method.

Once we have a full HTTP message, build the wsgi environ and delegate the response to the wsgi_callable() function.


Get the headers to send to the client.


Available once the headers have been sent to the client.

These are the bytes representing the first response line and the headers


Check if the response uses chunked transfer encoding.

Only use chunked responses when the client is speaking HTTP/1.1 or newer and there was no Content-Length header set.

start_response(status, response_headers, exc_info=None)[source]

WSGI compliant start_response callable, see pep3333.

The application may call start_response more than once, if and only if the exc_info argument is provided. More precisely, it is a fatal error to call start_response without the exc_info argument if start_response has already been called within the current invocation of the application.

  • status – an HTTP status string like 200 OK or 404 Not Found.
  • response_headers – a list of (header_name, header_value) tuples. It must be a Python list. Each header_name must be a valid HTTP header field-name (as defined by RFC 2616, Section 4.2), without a trailing colon or other punctuation.
  • exc_info – optional python sys.exc_info() tuple. This argument should be supplied by the application only if start_response is being called by an error handler.

The write() method.

HOP_HEADERS are not considered but no error is raised.

write(data, force=False)[source]

The write function returned by the start_response() method.

Required by the WSGI specification.

  • data – bytes to write
  • force – Optional flag used internally

a Future or the number of bytes written

Testing WSGI Environ

pulsar.apps.wsgi.server.test_wsgi_environ(path=None, method=None, headers=None, extra=None, https=False, loop=None, body=None, **params)[source]

An function to create a WSGI environment dictionary for testing.

  • url – the resource in the PATH_INFO.
  • method – the REQUEST_METHOD.
  • headers – optional request headers
  • extra – additional dictionary of parameters to add to params
  • params – key valued parameters
Params https:

a secure connection?


a valid WSGI environ dictionary.