This part of the documentation covers all the interfaces of Flask. For parts where Flask depends on external libraries, we document the most important right here and provide links to the canonical documentation.

Application Object

Module Objects

Incoming Request Data

class request

To access incoming request data, you can use the global request object. Flask parses incoming request data for you and gives you access to it through that global object. Internally Flask makes sure that you always get the correct data for the active thread if you are in a multithreaded environment.

The request object is an instance of a Request subclass and provides all of the attributes Werkzeug defines. This just shows a quick overview of the most important ones.


A MultiDict with the parsed form data from POST or PUT requests. Please keep in mind that file uploads will not end up here, but instead in the files attribute.


A MultiDict with the parsed contents of the query string. (The part in the URL after the question mark).


A CombinedMultiDict with the contents of both form and args.


A dict with the contents of all cookies transmitted with the request.


If the incoming form data was not encoded with a known mimetype the data is stored unmodified in this stream for consumption. Most of the time it is a better idea to use data which will give you that data as a string. The stream only returns the data once.


Contains the incoming request data as string in case it came with a mimetype Flask does not handle.


A MultiDict with files uploaded as part of a POST or PUT request. Each file is stored as FileStorage object. It basically behaves like a standard file object you know from Python, with the difference that it also has a save() function that can store the file on the filesystem.


The underlying WSGI environment.


The current request method (POST, GET etc.)


Provides different ways to look at the current URL. Imagine your application is listening on the following URL:


And a user requests the following URL:


In this case the values of the above mentioned attributes would be the following:












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.


Contains the parsed body of the JSON request if the mimetype of the incoming data was application/json. This requires Python 2.6 or an installed version of simplejson.

Response Objects


If you have the Flask.secret_key set you can use sessions in Flask applications. A session basically makes it possible to remember information from one request to another. The way Flask does this is by using a signed cookie. So the user can look at the session contents, but not modify it unless he knows the secret key, so make sure to set that to something complex and unguessable.

To access the current session you can use the session object:

class session

The session object works pretty much like an ordinary dict, with the difference that it keeps track on modifications.

The following attributes are interesting:


True if the session is new, False otherwise.


True if the session object detected a modification. Be advised that modifications on mutable structures are not picked up automatically, in that situation you have to explicitly set the attribute to True yourself. Here an example:

# this change is not picked up because a mutable object (here
# a list) is changed.
# so mark it as modified yourself
session.modified = True

If set to True the session life for permanent_session_lifetime seconds. The default is 31 days. If set to False (which is the default) the session will be deleted when the user closes the browser.

Application Globals

To share data that is valid for one request only from one function to another, a global variable is not good enough because it would break in threaded environments. Flask provides you with a special object that ensures it is only valid for the active request and that will return different values for each request. In a nutshell: it does the right thing, like it does for request and session.


Just store on this whatever you want. For example a database connection or the user that is currently logged in.

Useful Functions and Classes


Points to the application handling the request. This is useful for extensions that want to support multiple applications running side by side.


Raises an HTTPException for the given status code. For example to abort request handling with a page not found exception, you would call abort(404).


code -- the HTTP error code.

Message Flashing

Returning JSON


If JSON support is picked up, this will be the module that Flask is using to parse and serialize JSON. So instead of doing this yourself:

    import simplejson as json
except ImportError:
    import json

You can instead just do this:

from flask import json

For usage examples, read the json documentation.

The dumps() function of this json module is also available as filter called |tojson in Jinja2. Note that inside script tags no escaping must take place, so make sure to disable escaping with |safe if you intend to use it inside script tags:

<script type=text/javascript>
    doSomethingWith({{ user.username|tojson|safe }});

Note that the |tojson filter escapes forward slashes properly.

Template Rendering


Useful Internals


The internal LocalStack that is used to implement all the context local objects used in Flask. This is a documented instance and can be used by extensions and application code but the use is discouraged in general.

在 0.4 版本发生变更.

The request context is automatically popped at the end of the request for you. In debug mode the request context is kept around if exceptions happen so that interactive debuggers have a chance to introspect the data. With 0.4 this can also be forced for requests that did not fail and outside of DEBUG mode. By setting 'flask._preserve_context' to True on the WSGI environment the context will not pop itself at the end of the request. This is used by the test_client() for example to implement the deferred cleanup functionality.

You might find this helpful for unittests where you need the information from the context local around for a little longer. Make sure to properly pop() the stack yourself in that situation, otherwise your unittests will leak memory.