# Werkzeug

# Wrappers

You can import all these objects directly from `werkzeug`. Wrappers wrap the WSGI environment or the return value from a WSGI application so that it is another WSGI application (wraps a whole application).

## How they Work

Your WSGI application is always passed two arguments. The WSGI “environment” and the WSGI start_response function that is used to start the response phase. The `Request` class wraps the environ for easier access to request variables (form data, request headers etc.).

The `Response` on the other hand is a standard WSGI application that you can create. The simple hello world in Werkzeug looks like this:

    from werkzeug import Response
    application = Response('Hello World!')

To make it more useful you can replace it with a function and do some processing:

    from werkzeug import Request, Response

    def application(environ, start_response):
        request = Request(environ)
        response = Response("Hello %s!" % request.args.get('name', 'World!'))
        return response(environ, start_response)

Because this is a very common task the `Request` object provides a helper for that. The above code can be rewritten like this:

    from werkzeug import Request, Response

    @Request.application
    def application(request):
        return Response("Hello %s!" % request.args.get('name', 'World!'))

The application is still a valid WSGI application that accepts the environment and start_response callable.

## Base Wrappers

These objects implement a common set of operations. They are missing fancy addon functionality like user agent parsing or etag handling. These features are available by mixing in various mixin classes or using `Request` and `Response`.

class `werkzeug.``BaseRequest`(environ, populate_request=True, shallow=False)

  Very basic request object. This does not implement advanced stuff like entity tag parsing or cache controls. The request object is created with the WSGI environment as first argument and will add itself to the WSGI environment as `'werkzeug.request'` unless it’s created with populate_request set to False.

  There are a couple of mixins available that add additional functionality to the request object, there is also a class called Request which subclasses BaseRequest and all the important mixins.

  It’s a good idea to create a custom subclass of the `BaseRequest` and add missing functionality either via mixins or direct implementation. Here an example for such subclasses:

      from werkzeug import BaseRequest, ETagRequestMixin

      class Request(BaseRequest, ETagRequestMixin):
          pass

  Request objects are read only. As of 0.5 modifications are not allowed in any place. Unlike the lower level parsing functions the request object will use immutable objects everywhere possible.

  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.

  Per default the request object will be added to the WSGI environment as werkzeug.request to support the debugging system. If you don’t want that, set populate_request to False.

  If shallow is True the environment is initialized as shallow object around the environ. Every operation that would modify the environ in any way (such as consuming form data) raises an exception unless the shallow attribute is explicitly set to False. This is useful for middlewares where you don’t want to consume the form data by accident. A shallow request is not populated to the WSGI environment.

  Changed in version 0.5: read-only mode was enforced by using immutables classes for all data.

  `environ`
    The WSGI environment that the request object uses for data retrival.
  `shallow`
    True if this request object is shallow (does not modify `environ`), False otherwise.
  `_get_file_stream`(total_content_length, content_type, filename=None, content_length=None)

    Called to get a stream for the file upload.

    This must provide a file-like class with read(), readline() and seek() methods that is both writeable and readable.

    The default implementation returns a temporary file if the total content length is higher than 500KB. Because many browsers do not provide a content length for the files only the total content length matters.

    Changed in version 0.5: Previously this function was not passed any arguments. In 0.5 older functions not accepting any arguments are still supported for backwards compatibility.

    Parameters: | total_content_length – the total content length of all the data in the request combined. This value is guaranteed to be there. content_type – the mimetype of the uploaded file. filename – the filename of the uploaded file. May be None. content_length – the length of this file. This value is usually not provided because webbrowsers do not provide this value.

  `_form_parsing_failed`(error)

    Called if parsing of form data failed. This is currently only invoked for failed multipart uploads. By default this method does nothing.

    Parameter: | error – a ValueError object with a message why the parsing failed.

    New in version 0.5.1.

  `access_route`
    If a forwarded header exists this is a list of all ip addresses from the client ip to the last proxy server.
  classmethod `application`(f)

    Decorate a function as responder that accepts the request as first argument. This works like the `responder` decorator but the function is passed the request object as first argument:

        @Request.application
        def my_wsgi_app(request):
            return Response('Hello World!')

    Parameter: | f – the WSGI callable to decorate
    Returns: | a new WSGI callable

  `args`
    The parsed URL parameters as `ImmutableMultiDict`.
  `base_url`
    Like `url` but without the querystring
  `charset`
    the charset for the request, defaults to utf-8
  `cookies`
    The retrieved cookie values as regular dictionary.
  `data`

    This reads the buffered incoming data from the client into the string. Usually it’s a bad idea to access `data` because a client could send dozens of megabytes or more to cause memory problems on the server.

    To circumvent that make sure to check the content length first.

  `encoding_errors`
    the error handling procedure for errors, defaults to ‘ignore’
  `files`

    `MultiDict` object containing all uploaded files. Each key in `files` is the name from the `<input type="file" name="">`. Each value in `files` is a Werkzeug `FileStorage` object.

    Note that `files` will only contain data if the request method was POST or PUT and the `<form>` that posted to the request had `enctype="multipart/form-data"`. It will be empty otherwise.

    See the `MultiDict` / `FileStorage` documentation for more details about the used data structure.

  `form`
    Form parameters. Currently it’s not guaranteed that the `ImmutableMultiDict` returned by this function is ordered in the same way as the submitted form data.
  classmethod `from_values`(*args, **kwargs)

    Create a new request object based on the values provided. If environ is given missing values are filled from there. This method is useful for small scripts when you need to simulate a request from an URL. Do not use this method for unittesting, there is a full featured client object (`Client`) that allows to create multipart requests, support for cookies etc.

    This accepts the same options as the `EnvironBuilder`.

    Changed in version 0.5: This method now accepts the same arguments as `EnvironBuilder`. Because of this the environ parameter is now called environ_overrides.

    Returns: | request object

  `headers`
    The headers from the WSGI environ as immutable `EnvironHeaders`.
  `host`
    Just the host including the port if available.
  `host_url`
    Just the host with scheme.
  `is_behind_proxy`
    set to True if the application runs behind an HTTP proxy
  `is_multiprocess`
    boolean that is True if the application is served by a WSGI server that spawns multiple processes.
  `is_multithread`
    boolean that is True if the application is served by a multithreaded WSGI server.
  `is_run_once`
    boolean that is True if the application will be executed only once in a process lifetime. This is the case for CGI for example, but it’s not guaranteed that the exeuction only happens one time.
  `is_secure`
    True if the request is secure.
  `is_xhr`
    True if the request was triggered via a JavaScript XMLHttpRequest. This only works with libraries that support the X-Requested-With header and set it to “XMLHttpRequest”. Libraries that do that are prototype, jQuery and Mochikit and probably some more.
  `max_content_length`

    the maximum content length. This is forwarded to the form data parsing function (`parse_form_data`). When set and the `form` or `files` attribute is accessed and the parsing fails because more than the specified value is transmitted a `RequestEntityTooLarge` exception is raised.

    Have a look at Dealing with Request Data for more details.

    New in version 0.5.

  `max_form_memory_size`

    the maximum form field size. This is forwarded to the form data parsing function (`parse_form_data`). When set and the `form` or `files` attribute is accessed and the data in memory for post data is longer than the specified value a `RequestEntityTooLarge` exception is raised.

    Have a look at Dealing with Request Data for more details.

    New in version 0.5.

  `method`
    The transmission method. (For example `'GET'` or `'POST'`).
  `path`
    Requested path as unicode. This works a bit like the regular path info in the WSGI environment but will always include a leading slash, even if the URL root is accessed.
  `query_string`
    The URL parameters as raw bytestring.
  `remote_addr`
    The remote address of the client.
  `remote_user`
    If the server supports user authentication, and the script is protected, this attribute contains the username the user has authenticated as.
  `script_root`
    The root path of the script without the trailing slash.
  `stream`
    The parsed stream if the submitted data was not multipart or urlencoded form data. This stream is the stream left by the form data parser module after parsing. This is not the WSGI input stream but a wrapper around it that ensures the caller does not accidentally read past Content-Length.
  `url`
    The reconstructed current URL
  `url_root`
    The full URL root (with hostname), this is the application root.
  `values`
    Combined multi dict for `args` and `form`.

class `werkzeug.``BaseResponse`(response=None, status=None, headers=None, mimetype=None, content_type=None, direct_passthrough=False)

  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 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 know 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/ it becomes a charset parameter defined with the charset of the response object. 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 an `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 though unchanged (see `wrap_file` for more details.)

  `response`
    The application iterator. If constructed from a string this will be a list, otherwise the object provided as application iterator. (The first argument passed to `BaseResponse`)
  `headers`
    A `Headers` object representing the response headers.
  `status_code`
    The response status as integer.
  `direct_passthrough`
    If `direct_passthrough=True` was passed to the response object or if this attribute was set to True before using the response object as WSGI application, the wrapped iterator is returned unchanged. This makes it possible to pass a special wsgi.file_wrapper to the response object. See `wrap_file` for more details.
  `__call__`(environ, start_response)

    Process this response as WSGI application.

    Parameters: | environ – the WSGI environment. start_response – the response callable provided by the WSGI server.

  `close`()
    Close the wrapped response if possible.
  `data`
    The string representation of the request body. Whenever you access this property the request iterable is encoded and flattened. This can lead to unwanted behavior if you stream big data.
  `delete_cookie`(key, path='/', domain=None)

    Delete a cookie. Fails silently if key doesn’t exist.

    Parameters: | key – the key (name) of the cookie to be deleted. path – if the cookie that should be deleted was limited to a path, the path has to be defined here. domain – if the cookie that should be deleted was limited to a domain, that domain has to be defined here.

  `fix_headers`(environ)

    This is automatically called right before the response is started and should fix common mistakes in headers. For example location headers are joined with the root URL here.

    Parameter: | environ – the WSGI environment of the request to be used for the applied fixes.

  classmethod `force_type`(response, environ=None)

    Enforce that the WSGI response is a response object of the current type. Werkzeug will use the `BaseResponse` internally in many situations like the exceptions. If you call `get_response` on an exception you will get back a regular `BaseResponse` object, even if you are using a custom subclass.

    This method can enforce a given response type, and it will also convert arbitrary WSGI callables into response objects if an environ is provided:

        # convert a Werkzeug response object into an instance of the
        # MyResponseClass subclass.
        response = MyResponseClass.force_type(response)

        # convert any WSGI application into a response object
        response = MyResponseClass.force_type(response, environ)

    This is especially useful if you want to post-process responses in the main dispatcher and use functionality provided by your subclass.

    Keep in mind that this will modify response objects in place if possible!

    Parameters: | response – a response object or wsgi application. environ – a WSGI environment object.
    Returns: | a response object.

  `freeze`()
    Call this method if you want to make your response object ready for being pickled. This buffers the generator if there is one.
  classmethod `from_app`(app, environ, buffered=False)

    Create a new response object from an application output. This works best if you pass it an application that returns a generator all the time. Sometimes applications may use the write() callable returned by the start_response function. This tries to resolve such edge cases automatically. But if you don’t get the expected output you should set buffered to True which enforces buffering.

    Parameters: | app – the WSGI application to execute. environ – the WSGI environment to execute against. buffered – set to True to enforce buffering.
    Returns: | a response object.

  `header_list`
    This returns the headers in the target charset as list. It’s used in __call__ to get the headers for the response.
  `is_streamed`

    If the response is streamed (the response is not a sequence) this property is True. In this case streamed means that there is no information about the number of iterations. This is usully True if a generator is passed to the response object.

    This is useful for checking before applying some sort of post filtering that should not take place for streamed responses.

  `iter_encoded`(charset=None)
    Iter the response encoded with the encoding specified. If no encoding is given the encoding from the class is used. Note that this does not encode data that is already a bytestring. If the response object is invoked as WSGI application the return value of this method is used as application iterator except if `direct_passthrough` was activated.
  `set_cookie`(key, value='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=False)

    Sets a cookie. The parameters are the same as in the cookie Morsel object in the Python standard library but it accepts unicode data, too.

    Parameters: | key – the key (name) of the cookie to be set. value – the value of the cookie. max_age – should be a number of seconds, or None (default) if the cookie should last only as long as the client’s browser session. expires – should be a datetime object or UNIX timestamp. domain – if you want to set a cross-domain cookie. For example, `domain=".example.com"` will set a cookie that is readable by the domain `www.example.com`, `foo.example.com` etc. Otherwise, a cookie will only be readable by the domain that set it. path – limits the cookie to a given path, per default it will span the whole domain.

## Mixin Classes

Werkzeug also provides helper mixins for various HTTP related functionality such as etags, cache control, user agents etc. When subclassing you can mix those classes in to extend the functionality of the `BaseRequest` or `BaseResponse` object. Here a small example for a request object that parses accept headers:

    from werkzeug import BaseRequest, AcceptMixin

    class Request(BaseRequest, AcceptMixin):
        pass

The `Request` and `Response` classes subclass the `BaseRequest` and `BaseResponse` classes and implement all the mixins Werkzeug provides:

class `werkzeug.``Request`(environ, populate_request=True, shallow=False)

  Full featured request object implementing the following mixins:

  - `AcceptMixin` for accept header parsing
  - `ETagRequestMixin` for etag and cache control handling
  - `UserAgentMixin` for user agent introspection
  - `AuthorizationMixin` for http auth handling
  - `CommonRequestDescriptorsMixin` for common headers

class `werkzeug.``Response`(response=None, status=None, headers=None, mimetype=None, content_type=None, direct_passthrough=False)

  Full featured response object implementing the following mixins:

  - `ETagResponseMixin` for etag and cache control handling
  - `ResponseStreamMixin` to add support for the stream property
  - `CommonResponseDescriptorsMixin` for various HTTP descriptors
  - `WWWAuthenticateMixin` for HTTP authentication support

class `werkzeug.``AcceptMixin`

  A mixin for classes with an `environ` attribute to get all the HTTP accept headers as `Accept` objects (or subclasses thereof).

  `accept_charsets`
    List of charsets this client supports as `CharsetAccept` object.
  `accept_encodings`
    List of encodings this client accepts. Encodings in a HTTP term are compression encodings such as gzip. For charsets have a look at `accept_charset`.
  `accept_languages`
    List of languages this client accepts as `LanguageAccept` object.
  `accept_mimetypes`
    List of mimetypes this client supports as `MIMEAccept` object.

class `werkzeug.``AuthorizationMixin`

  Adds an `authorization` property that represents the parsed value of the Authorization header as `Authorization` object.

  `authorization`
    The Authorization object in parsed form.

class `werkzeug.``ETagRequestMixin`

  Add entity tag and cache descriptors to a request object or object with a WSGI environment available as `environ`. This not only provides access to etags but also to the cache control header.

  `cache_control`
    A `RequestCacheControl` object for the incoming cache control headers.
  `if_match`
    An object containing all the etags in the If-Match header.
  `if_modified_since`
    The parsed If-Modified-Since header as datetime object.
  `if_none_match`
    An object containing all the etags in the If-None-Match header.
  `if_unmodified_since`
    The parsed If-Unmodified-Since header as datetime object.

class `werkzeug.``ETagResponseMixin`

  Adds extra functionality to a response object for etag and cache handling. This mixin requires an object with at least a headers object that implements a dict like interface similar to `Headers`.

  `add_etag`(overwrite=False, weak=False)
    Add an etag for the current response if there is none yet.
  `cache_control`
    The Cache-Control general-header field is used to specify directives that MUST be obeyed by all caching mechanisms along the request/response chain.
  `freeze`(no_etag=False)
    Call this method if you want to make your response object ready for pickeling. This buffers the generator if there is one. This also sets the etag unless no_etag is set to True.
  `get_etag`()
    Return a tuple in the form `(etag, is_weak)`. If there is no ETag the return value is `(None, None)`.
  `make_conditional`(request_or_environ)

    Make the response conditional to the request. This method works best if an etag was defined for the response already. The add_etag method can be used to do that. If called without etag just the date header is set.

    This does nothing if the request method in the request or environ is anything but GET or HEAD.

    It does not remove the body of the response because that’s something the `__call__` function does for us automatically.

    Returns self so that you can do `return resp.make_conditional(req)` but modifies the object in-place.

    Parameter: | request_or_environ – a request object or WSGI environment to be used to make the response conditional against.

  `set_etag`(etag, weak=False)
    Set the etag, and override the old one if there was one.

class `werkzeug.``ResponseStreamMixin`

  Mixin for `BaseRequest` subclasses. Classes that inherit from this mixin will automatically get a `stream` property that provides a write-only interface to the response iterable.

  `stream`
    The response iterable as write-only stream.

class `werkzeug.``CommonRequestDescriptorsMixin`

  A mixin for `BaseRequest` subclasses. Request objects that mix this class in will automatically get descriptors for a coupl eof HTTP headers with automatic type conversion.

  New in version 0.5.

  `content_length`
    The Content-Length entity-header field indicates the size of the entity-body in bytes or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET.
  `content_type`
    The Content-Type entity-header field indicates the media type of the entity-body sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request been a GET.
  `date`
    The Date general-header field represents the date and time at which the message was originated, having the same semantics as orig-date in RFC 822.
  `max_forwards`
    The Max-Forwards request-header field provides a mechanism with the TRACE and OPTIONS methods to limit the number of proxies or gateways that can forward the request to the next inbound server.
  `mimetype`
    Like `content_type` but without parameters (eg, without charset, type etc.). For example if the content type is `text/html; charset=utf-8` the mimetype would be `'text/html'`.
  `mimetype_params`
    The mimetype parameters as dict. For example if the content type is `text/html; charset=utf-8` the params would be `{'charset': 'utf-8'}`.
  `pragma`
    The Pragma general-header field is used to include implementation-specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives.
  `referrer`
    The Referer[sic] request-header field allows the client to specify, for the server’s benefit, the address (URI) of the resource from which the Request-URI was obtained (the “referrer”, although the header field is misspelled).

class `werkzeug.``CommonResponseDescriptorsMixin`

  A mixin for `BaseResponse` subclasses. Response objects that mix this class in will automatically get descriptors for a couple of HTTP headers with automatic type conversion.

  `age`

    The Age response-header field conveys the sender’s estimate of the amount of time since the response (or its revalidation) was generated at the origin server.

    Age values are non-negative decimal integers, representing time in seconds.

  `allow`
    The Allow entity-header field lists the set of methods supported by the resource identified by the Request-URI. The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. An Allow header field MUST be present in a 405 (Method Not Allowed) response.
  `content_encoding`
    The Content-Encoding entity-header field is used as a modifier to the media-type. When present, its value indicates what additional content codings have been applied to the entity-body, and thus what decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field.
  `content_language`
    The Content-Language entity-header field describes the natural language(s) of the intended audience for the enclosed entity. Note that this might not be equivalent to all the languages used within the entity-body.
  `content_length`
    The Content-Length entity-header field indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET.
  `content_location`
    The Content-Location entity-header field MAY be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location separate from the requested resource’s URI.
  `content_md5`
    The Content-MD5 entity-header field, as defined in RFC 1864, is an MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body. (Note: a MIC is good for detecting accidental modification of the entity-body in transit, but is not proof against malicious attacks.)
  `content_type`
    The Content-Type entity-header field indicates the media type of the entity-body sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request been a GET.
  `date`
    The Date general-header field represents the date and time at which the message was originated, having the same semantics as orig-date in RFC 822.
  `expires`
    The Expires entity-header field gives the date/time after which the response is considered stale. A stale cache entry may not normally be returned by a cache.
  `last_modified`
    The Last-Modified entity-header field indicates the date and time at which the origin server believes the variant was last modified.
  `location`
    The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource.
  `mimetype`
    The mimetype (content type without charset etc.)
  `mimetype_params`

    The mimetype parameters as dict. For example if the content type is `text/html; charset=utf-8` the params would be `{'charset': 'utf-8'}`.

    New in version 0.5.

  `retry_after`

    The Retry-After response-header field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client.

    Time in seconds until expiration or date.

  `vary`
    The Vary field value indicates the set of request-header fields that fully determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request without revalidation.

class `werkzeug.``WWWAuthenticateMixin`

  Adds a `www_authenticate` property to a response object.

  `www_authenticate`
    The WWW-Authenticate header in a parsed form.

class `werkzeug.``UserAgentMixin`

  Adds a user_agent attribute to the request object which contains the parsed user agent of the browser that triggered the request as UserAgent object.

  `user_agent`
    The current user agent.