werkzeug.BaseResponse¶

class werkzeug.BaseResponse(response=None, status=None, headers=None, mimetype=None, content_type=None, direct_passthrough=False)[source]¶

Base response class. The most important fact about a response object is that it’s a regular WSGI application. It’s initialized with a couple of response parameters (headers, body, status code etc.) and will start a valid WSGI response when called with the environ and start response callable.

Because it’s a WSGI application itself processing usually ends before the actual response is sent to the server. This helps debugging systems because they can catch all the exceptions before responses are started.

Here a small example WSGI application that takes advantage of the response objects:

from werkzeug.wrappers import BaseResponse as Response

def index():
    return Response('Index page')

def application(environ, start_response):
    path = environ.get('PATH_INFO') or '/'
    if path == '/':
        response = index()
    else:
        response = Response('Not Found', status=404)
    return response(environ, start_response)

Like BaseRequest which object is lacking a lot of functionality implemented in mixins. This gives you a better control about the actual API of your response objects, so you can create subclasses and add custom functionality. A full featured response object is available as Response which implements a couple of useful mixins.

To enforce a new type of already existing responses you can use the force_type() method. This is useful if you’re working with different subclasses of response objects and you want to post process them with a known interface.

Per default the request object will assume all the text data is utf-8 encoded. Please refer to the unicode chapter for more details about customizing the behavior.

Response can be any kind of iterable or string. If it’s a string it’s considered being an iterable with one item which is the string passed. Headers can be a list of tuples or a Headers object.

Special note for mimetype and content_type: For most mime types mimetype and content_type work the same, the difference affects only ‘text’ mimetypes. If the mimetype passed with mimetype is a mimetype starting with text/, the charset parameter of the response object is appended to it. In contrast the content_type parameter is always added as header unmodified.

Changed in version 0.5: the direct_passthrough parameter was added.

Parameters:

response – a string or response iterable. status – a string with a status or an integer with the status code. headers – a list of headers or a Headers object. mimetype – the mimetype for the request. See notice above. content_type – the content type for the request. See notice above. direct_passthrough – if set to True iter_encoded() is not called before iteration which makes it possible to pass special iterators through unchanged (see wrap_file() for more details.)