User’s Guide

Starting and stopping

The server can be started by instatiating it and then calling the pytest_httpserver.HTTPServer.start() method. This will start the server in a separate thread, so you will need to make sure that the pytest_httpserver.HTTPServer.stop() method is called before your code exits.

When using the pytest plugin, the server is started at the first usage of the server and it will remain running for the whole test suite. For each test function, a clear http server will be used to avoid crosstalk.

A free TCP port needs to be specified when instantiating the server. Setting 0 as the port number will select a free (ephemeral) TCP port which is guaranteed to be free. This is the default behavior.

Specifying the bind host and port can be done in several ways:

  • Setting PYTEST_HTTPSERVER_HOST and PYTEST_HTTPSERVER_PORT will change the bind host and bind port, respectively.
  • If pytest plugin is not used, the DEFAULT_LISTEN_HOST and DEFAULT_LISTEN_PORT class attributes can be set on the HTTPServer class.
  • bind host and port can be specified for the constructor of the pytest_httpserver.server.HTTPServer class.
  • Overriding the httpserver_listen_address fixture in pytest.


By configuring the server means registering handlers for specific requests. Once a request matches with the configuration the specified response handler is fired and the reponse is served.


When registering a pytest_httpserver.server.RequestMatcher, it can use various parts of the HTTP request to be matched: URI, method, data, headers, and query string can be specified.

The following can be matched:

  • uri: a string, a regexp or an pytest_httpserver.server.URIPattern object
  • method: GET/POST/…, specified as string
  • data: a string or bytes. It is possible to match with arbitrary byte data.
  • headers: a str-str dictionary or a pytest_httpserver.server.HeaderValueMatcher object which matches each header with its own provided callable
  • query_string: a string, bytes or a dict specifying the key-value pairs of the query string

pytest_httpserver.server.HTTPServer also determines how these matchers are looked up and what their lifetime is. You can register handlers which handle any amount of requests, but you can also register one-shot handlers which only handle one request and then they disappear.

Also, there’s ordered handlers which also specify the order of the requests to be handled. Not matching the order of their registration, the server will refuse to serve any further requests.

With all of these, you can create a server with very permissive to very strict request handling.


Once the request is matched with one of the matchers, the handler gets fired, which can return a static response or you can create a function which can return a dynamic response. When dealing with static responses you can determine all parts of the http response (status, headers, content, etc), and you can also specify a JSON-serializable object to be returned as a json.

Waiting for test completion or errors

It is possible to wait until all oneshot and ordered handlers are exhausted or any error happened. This is provided by a context manager which waits until one of these events occured. This can be further customized by pytest_httpserver.server.WaitingSettings object to raise or not raise assertion.

Debugging errors while testing

When the tests are running against the server and no matcher can be found for the given request, the server replies with HTTP status 500, and a short error text. This is not very helpful in most cases so if you want to check what is the situation, you should call pytest_httpserver.HTTPServer.format_matchers() or pytest_httpserver.HTTPServer.check_assertions() methods. The first one returns a human-readable string representation of the matchers registered. The second one raises AssertionError with the errors happened during the testing in the server.

Also there’s a pytest_httpserver.HTTPServer.log attribute which contains the request-reponse object pairs what the server handled.