WebOb provides objects for HTTP requests and responses. Specifically it does this by wrapping the WSGI request environment and response status/headers/app_iter(body).
The request and response objects provide many conveniences for parsing HTTP request and forming HTTP responses. Both objects are read/write: as a result, WebOb is also a nice way to create HTTP requests and parse HTTP responses; however, we won't cover that use case in this document. The reference documentation shows many examples of creating requests.
Reference material for every public API exposed by WebOb:
webob.client-- Send WSGI requests over HTTP
webob.dec-- WSGIfy decorator
webob.exc-- WebOb Exceptions
webob.multidict-- multi-value dictionary object
webob.static-- Serving static files
webob-- Request/Response objects
The request object is a wrapper around the WSGI environ dictionary. This
dictionary contains keys for each header, keys that describe the
request (including the path and query string), a file-like object for
the request body, and a variety of custom keys. You can always access
the environ with
Some of the most important and interesting attributes of a request object are the following:
- The request method, e.g.,
- A dictionary-like object with all the variables in the query string.
- A dictionary-like object with all the variables in the request
body. This only has variables if the request was a
POSTand it is a form submission.
- A dictionary-like object with a combination of everything in
- The contents of the body of the request. This contains the entire
request body as a string. This is useful when the request is a
POSTthat is not a form submission, or a request like a
PUT. You can also get
req.body_filefor a file-like object.
- A simple dictionary of all the cookies.
- A dictionary of all the headers. This dictionary is case-insensitive.
req.urlvarsis the keyword parameters associated with the request URL.
req.urlargsare the positional parameters. These are set by products like Routes and Selector.
Also for standard HTTP request headers, there are usually attributes, e.g.,
properties expose the parsed form of each header, for whatever parsing makes
sense. For instance,
req.if_modified_since returns a datetime object (or
None if the header is was not provided). Details are in the Request
In addition to these attributes, there are several ways to get the URL
of the request. I'll show various values for an example URL
http://localhost/app-root/doc?article_id=10, where the application
is mounted at
- The full request URL, with query string, e.g.,
- The URL of the application (just the
SCRIPT_NAMEportion of the path, not
- The URL with the host, e.g.,
- Gives a URL, relative to the current URL. If
to_applicationis True, then the URL is resolved relative to
There are several methods in
webob.Request but only a few you'll use
- Creates a new request with blank information, based at the given
URL. This can be useful for subrequests and artificial requests.
You can also use
req.copy()to copy an existing request, or for subrequests
req.copy_get()which copies the request but always turns it into a GET (which is safer to share for subrequests).
- This method calls the given WSGI application with this request, and returns a Response object. You can also use this for subrequests or testing.
Many of the properties in the request object will return unicode
values if the request encoding/charset is provided. The client can
indicate the charset with something like
application/x-www-form-urlencoded; charset=utf8, but browsers seldom
set this. You can set the charset with
req.charset = 'utf8', or
during instantiation with
Request(environ, charset='utf8'). If
Request you can also set
charset as a class-level
If it is set, then
req.cookies will contain unicode strings.
The response object looks a lot like the request object, though with
some differences. The request object wraps a single
object; the response object has three fundamental parts (based on
- The response code plus message, like
'200 OK'. To set the code without the reason, use
response.status_code = 200.
- A list of all the headers, like
[('Content-Type', 'text/html')]. There's a case-insensitive dictionary-like object in
response.headersthat also allows you to access these same headers.
- An iterable (such as a list or generator) that will produce the
content of the response. This is also accessible as
response.unicode_body(a unicode object, informed by
response.body_file(a file-like object; writing to it appends to
Everything else in the object derives from this underlying state. Here are the highlights:
- The content type not including the
charsetparameter. Typical use:
response.content_type = 'text/html'. You can subclass
Responseand add a class-level attribute
default_content_typeto set this automatically on instantiation.
charsetparameter of the content-type, it also informs encoding in
response.content_type_paramsis a dictionary of all the parameters.
response.set_cookie(name=None, value='', max_age=None, path='/', domain=None, secure=False, httponly=False, comment=None, overwrite=False):
- Set a cookie. The keyword arguments control the various cookie
max_ageargument is the length for the cookie to live in seconds (you may also use a timedelta object).
response.delete_cookie(key, path='/', domain=None):
- Delete a cookie from the client. This sets
max_ageto 0 and the cookie value to
- This makes this response cacheable for the given number of seconds,
secondsis 0 then the response is uncacheable (this also sets the
response(environ, start_response): The response object is a WSGI
- application. As an application, it acts according to how you
create it. It can do conditional responses if you pass
conditional_response=Truewhen instantiating (or set that attribute later). It can also do HEAD and Range requests.
Like the request, most HTTP response headers are available as
properties. These are parsed, so you can do things like
response.last_modified = os.path.getmtime(filename).
Instantiating the Response¶
Of course most of the time you just want to make a response. Generally any attribute of the response can be passed in as a keyword argument to the class, e.g.:
response = Response(body='hello world!', content_type='text/plain')
The status defaults to
'200 OK'. The content_type defaults to
default_content_type which is set to text/html, although if you subclass
Response and set
default_content_type, you can override this behavior.
To facilitate error responses like 404 Not Found, the module
webob.exc contains classes for each kind of error response. These
include boring but appropriate error bodies.
Each class is named
* is the reason for
the error. For instance,
webob.exc.HTTPNotFound. It subclasses
Response, so you can manipulate the instances in the same way. A
typical example is:
response = HTTPNotFound('There is no such resource') # or: response = HTTPMovedPermanently(location=new_url)
You can use this like:
try: # ... stuff ... raise HTTPNotFound('No such resource') except HTTPException, e: return e(environ, start_response)
The exceptions are still WSGI applications, but you cannot set
charset, etc., on these exception
Several parts of WebOb use a "multidict", which is a dictionary where a
key can have multiple values. The quintessential example is a query
pref variable has two
In a multidict, when you do
request.GET['pref'], you'll get back
'blue' (the last value of
pref). Sometimes returning a
string and other times returning a list is a cause of frequent
exceptions. If you want all the values back, use
request.GET.getall('pref'). If you want to be sure there is one
and only one value, use
request.GET.getone('pref'), which will
raise an exception if there is zero or more than one value for
When you use operations like
request.GET.items(), you'll get back
[('pref', 'red'), ('pref', 'blue')]. All the
key/value pairs will show up. Similarly
['pref', 'pref']. Multidict is a view on a list of
tuples; all the keys are ordered, and all the values are ordered.
The file-serving example shows how to do more advanced HTTP techniques, while the comment middleware example shows middleware. For applications, it's more reasonable to use WebOb in the context of a larger framework. Pyramid, and its predecessor Pylons, both use WebOb.
Status and License¶
You can clone the source code with:
$ git clone https://github.com/Pylons/webob.git
Report issues on the issue tracker.
WebOb is released under an MIT-style license.