You can import all these objects directly from werkzeug.
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.
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 should be considered read only. Even though the object doesn’t enforce read only access everywhere you should never modify any data on the object itself unless you know exactly what you are doing.
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 enviornment 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.
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: |
|
|---|
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 |
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 circument that make sure to check the content length first.
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.
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 in werkzeug.test that allows to create multipart requests etc.
This accepts the same options as the create_environ() function and additionally an environ parameter that can contain values which will override the values from dict returned by create_environ().
Additionally a dict passed to query_string will be encoded in the request class charset.
| Returns: | request object |
|---|
Works like peek_path_info().
New in version 0.5.
Works like pop_path_info() but updates script_name and path_info which are per-se read-only attributes.
New in version 0.5.
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 constrast the content_type parameter is always added as header unmodified.
Changed in version 0.5: the direct_passthrough parameter was added.
| Parameters: |
|
|---|
Process this response as WSGI application.
| Parameters: |
|
|---|
Delete a cookie. Fails silently if key doesn’t exist.
| Parameters: |
|
|---|
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. |
|---|
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: |
|
|---|---|
| Returns: | a response object. |
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: |
|
|---|---|
| Returns: | a response object. |
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.
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: |
|
|---|
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:
Full featured request object implementing the following mixins:
Full featured response object implementing the following mixins:
A mixin for classes with an environ attribute to get and all the HTTP accept headers as Accept objects (or subclasses thereof).
Adds an authorization property that represents the parsed value of the Authorization header as Authorization object.
Add entity tag and cache descriptors to a request object or object with an WSGI environment available as environ. This not only provides access to etags but also to the cache control header.
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.
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 enviorn 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. |
|---|
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.
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.
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.
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.
Adds a www_authenticate property to a response object.