2. What ? Why ? And How ?
• A specification for an interface between a web
server and web application
• Allows servers, frameworks, applications to
evolve independent of each other
• Allows easy intergration of middlewares into
existing applications and servers
• Outlines the Operations and Responses a server
expects from an application and vice versa
3. Components of a web service
Client
Internet Web Server
Middleware
Application
Application1
Application2
5. Web Application
● Frameworks
– Allow quicker application development cycle
– Abstract all mundane jobs and allows user to concentrate on
logic/business
– Often use several tools like
● Templating engine – For generating page layout from datastructure
● PasteDeploy – For loading and chaining multiple web applications
● Routers – For routing a http request to a correct application
● Applications themselves may be chained to implement a
complex logic
● Some of the middleware may be third party applications
6. Examples
● Frameworks
– Django
– Flask
●
Theming
– Bootstrap
● Templating engine
– Jinja
– Mako
●
Middleware
– Ldap authentication using django
● Some of these may perform all other the above jobs. But the user
has the power to mix and match, thanks to wsgi.
7. Play by the rules
● Application has to be a callable. Anything with a
__call__ method with do. Methods, Classes,
Objects all are welcome.
● Application should handle any number of calls.
Server invokes application once for every http
request.
● Application returns and Iterable that yields
bytestrings.
● Server iterates over the Iterable and sends the
data without buffering.
8. More rules
● Application accepts two objects, name not a
contraint
– environ – A dictionary of request , os and wsgi params
– start_response – A callable that
● accepts two params
– Status – HTTP Status String object
– Headers -- HTTP Response headers List of tuples of header-value
– exec_info (optional) – typically the result of 'sys.exc_info()'
● And returns one
– Write – A callable that inturn accepts one argument
● Body – A bytestring to be sent to the client
– Write – Sends the bytestring to the client
– This is for legacy application only. New applications must not use this
interface
9. More rules
● Application must call start_response with appropriate
arguments before returning
● Server stores the Status and Headers, but will wait untill
Applications returns an Iterable and the Iterable has
yielded its first bytestring
● If Application sends an 'Content-Length' header to
start_response, Server should not send any more data
to than specified by the length
● If Application sends exec_info optional argument server
should erase the
10. Server receives request
Server extract request headers
And populates 'environ'
Server calls
Application(environ, start_response)
Application executes Logic
Application calls
start_respons(status, headers)
start_response
saves status and headers
Appliation returns
body
Server returns status,
headers and body
Server validates status,
headers and body
11. Middlewares
● Plays both server and application game
● Secretly slips between server, application and
other middlewares
● Absolutely Transparent
● Used to integrate apps built using different
frameworks, third party modules, routing, load
balancing, anything else you wish for
12. Getting Dirty
from wsgiref.simple_server import make_server
def my_application(environ, start_response):
response_headers = [('Content-Type', 'text/html'),
('Akilesh', 'Cool head')]
status_code = '200 OK'
writer = start_response(status_code, response_headers)
# ignore the writer
# it exists only for legacy applications
ret = {'request method': environ['REQUEST_METHOD'],
'path': environ['PATH_INFO'],
'query string': environ['QUERY_STRING']}
return str(ret)
httpd = make_server('localhost', 9090, my_application)
httpd.serve_forever()