The separation of binary and text data in Python 3 poses a problem for WSGI, as it specifies that header data should be strings, while it sometimes needs to be binary and sometimes text. This works in Python 2 where text and binary data both are kept in "string" variables, but in Python 3 binary data is kept in "bytes" variables and "string" variables are for unicode text data. An updated version of the WSGI specification that deals with this is PEP 3333.
A reworked WSGI spec Web3 has also been proposed, specified in PEP444. This standard is an incompatible derivative of WSGI designed to work on Python 2.6, 2.7, 3.1+.
Wrappers
The server or gateway invokes the application callable once for each request it receives from an HTTP client, that is directed at the application.
Currently wrappers are available for FastCGI, CGI, SCGI, AJP (using flup), twisted.web, Apache (using mod_wsgi or mod_python), Nginx (using mod_wsgi), and Microsoft IIS (using WFastCGI, isapi-wsgi, PyISAPIe, or an ASP gateway).
Currently wrappers are available for FastCGI, CGI, SCGI, AJP (using flup), twisted.web, Apache (using mod_wsgi or mod_python), Nginx (using mod_wsgi), and Microsoft IIS (using WFastCGI, isapi-wsgi, PyISAPIe, or an ASP gateway).
Example of calling an application
An example of calling an application and retrieving its response:
def call_application(app, environ): body = [] status_headers = [None, None] def start_response(status, headers): status_headers[:] = [status, headers] return body.append(status_headers) app_iter = app(environ, start_response) try: for item in app_iter: body.append(item) finally: if hasattr(app_iter, 'close'): app_iter.close() return status_headers[0], status_headers[1], ''.join(body) status, headers, body = call_application(app, {...environ...})
Example application
A WSGI-compatible “Hello World” application written in Python:
def application(environ, start_response):
start_response('200 OK', [('Content-Type', 'text/plain')])
yield 'Hello World\n'
Where:
Line 1 defines a callable[4] named application, which takes two parameters, environ and start_response. environ is a dictionary containing environment variables in CGI. start_response is a callable taking two required parameters status and response_headers.
Line 2 calls start_response, specifying "200 OK" as the status and a "Content-Type" header.
Line 3 returns the body of response as a string literal.
def application(environ, start_response):
start_response('200 OK', [('Content-Type', 'text/plain')])
yield 'Hello World\n'
Where:
Line 1 defines a callable[4] named application, which takes two parameters, environ and start_response. environ is a dictionary containing environment variables in CGI. start_response is a callable taking two required parameters status and response_headers.
Line 2 calls start_response, specifying "200 OK" as the status and a "Content-Type" header.
Line 3 returns the body of response as a string literal.
Specification overview
The WSGI has two sides: the "server" or "gateway" side (often the web server like Apache, Nignx), and the "application" or "framework" side (the python script itself). To process a WSGI request, the server side executes the application and provides environment information and a callback function to the application side. The application processes the request, and returns the response to the server side using the callback function it was provided.
The So-called WSGI middleware sits in the middle of the server and application thus implements both sides of the API. The server after receiving request from a client forwards it to he middleware using WSGI, when after processing it sends a request to another WSGI script/application who's response is forwarded to the client via the middleware and ultimately via the server. There maybe multiple middlewares, thus forming a stack of WSGI compliant applications.
A "middleware" component can perform such functions as:
Routing a request to different application objects based on the target URL, after changing the environment variables accordingly.
Allowing multiple applications or frameworks to run side-by-side in the same process
Load balancing and remote processing, by forwarding requests and responses over a network
Perform content postprocessing, such as applying XSLT stylesheets
The So-called WSGI middleware sits in the middle of the server and application thus implements both sides of the API. The server after receiving request from a client forwards it to he middleware using WSGI, when after processing it sends a request to another WSGI script/application who's response is forwarded to the client via the middleware and ultimately via the server. There maybe multiple middlewares, thus forming a stack of WSGI compliant applications.
A "middleware" component can perform such functions as:
Routing a request to different application objects based on the target URL, after changing the environment variables accordingly.
Allowing multiple applications or frameworks to run side-by-side in the same process
Load balancing and remote processing, by forwarding requests and responses over a network
Perform content postprocessing, such as applying XSLT stylesheets
Idea
Python web application frameworks have been a problem for new Python users because the choice of web framework would limit the choice of usable web servers, and vice versa. Python applications were often designed for only one of CGI, FastCGI, mod_python or some other custom API of a specific web-server.
WSGI was created as a low-level interface between web servers and web applications or frameworks to promote common ground for portable web application development.
WSGI was created as a low-level interface between web servers and web applications or frameworks to promote common ground for portable web application development.
Web Server Gateway Interface
The Web Server Gateway Interface (WSGI) is a specification for simple and universal interface between web servers and web applications or frameworks for the Python programming language. It was originally specified in PEP 333 authored by Phillip J. Eby, and published on 7 December 2003. It has since been adopted as a standard for Python web application development. The latest version of the specification is v1.0.1, also known as PEP 3333, published on 26 September 2010.
Load limits
A web server (program) has defined load limits, because it can handle only a limited number of concurrent client connections (usually between 2 and 80,000, by default between 500 and 1,000) per IP address (and TCP port) and it can serve only a certain maximum number of requests per second depending on:
its own settings,
the HTTP request type,
whether the content is static or dynamic,
whether the content is cached, and
the hardware and software limitations of the OS of the computer on which the web server runs.
When a web server is near to or over its limit, it becomes unresponsive.
Causes of overload
At any time web servers can be overloaded due to:
Excess legitimate web traffic. Thousands or even millions of clients connecting to the web site in a short interval, e.g., Slashdot effect;
Distributed Denial of Service attacks. A denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS attack) is an attempt to make a computer or network resource unavailable to its intended users;
Computer worms that sometimes cause abnormal traffic because of millions of infected computers (not coordinated among them);
XSS viruses can cause high traffic because of millions of infected browsers and/or web servers;
Internet bots Traffic not filtered/limited on large web sites with very few resources (bandwidth, etc.);
Internet (network) slowdowns, so that client requests are served more slowly and the number of connections increases so much that server limits are reached;
Web servers (computers) partial unavailability. This can happen because of required or urgent maintenance or upgrade, hardware or software failures, back-end (e.g., database) failures, etc.; in these cases the remaining web servers get too much traffic and become overloaded.
Symptoms of overload
The symptoms of an overloaded web server are:
Requests are served with (possibly long) delays (from 1 second to a few hundred seconds).
The web server returns an HTTP error code, such as 500, 502, 503, 504, 408, or even 404, which is inappropriate for an overload condition.
The web server refuses or resets (interrupts) TCP connections before it returns any content.
In very rare cases, the web server returns only a part of the requested content. This behavior can be considered a bug, even if it usually arises as a symptom of overload.
Anti-overload techniques
To partially overcome above average load limits and to prevent overload, most popular web sites use common techniques like:
Managing network traffic, by using:
Firewalls to block unwanted traffic coming from bad IP sources or having bad patterns
HTTP traffic managers to drop, redirect or rewrite requests having bad HTTP patterns
Bandwidth management and traffic shaping, in order to smooth down peaks in network usage
Deploying web cache techniques
Using different domain names to serve different (static and dynamic) content by separate web servers, i.e.:
http://images.example.com
http://www.example.com
Using different domain names and/or computers to separate big files from small and medium-sized files; the idea is to be able to fully cache small and medium-sized files and to efficiently serve big or huge (over 10 - 1000 MB) files by using different settings
Using many internet servers (programs) per computer, each one bound to its own network card and IP address
Using many internet servers (computers) that are grouped together behind a load balancer so that they act or are seen as one big web server
Adding more hardware resources (i.e. RAM, disks) to each computer
Tuning OS parameters for hardware capabilities and usage
Using more efficient computer programs for web servers, etc.
Using other workarounds, especially if dynamic content is involved
its own settings,
the HTTP request type,
whether the content is static or dynamic,
whether the content is cached, and
the hardware and software limitations of the OS of the computer on which the web server runs.
When a web server is near to or over its limit, it becomes unresponsive.
Causes of overload
At any time web servers can be overloaded due to:
Excess legitimate web traffic. Thousands or even millions of clients connecting to the web site in a short interval, e.g., Slashdot effect;
Distributed Denial of Service attacks. A denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS attack) is an attempt to make a computer or network resource unavailable to its intended users;
Computer worms that sometimes cause abnormal traffic because of millions of infected computers (not coordinated among them);
XSS viruses can cause high traffic because of millions of infected browsers and/or web servers;
Internet bots Traffic not filtered/limited on large web sites with very few resources (bandwidth, etc.);
Internet (network) slowdowns, so that client requests are served more slowly and the number of connections increases so much that server limits are reached;
Web servers (computers) partial unavailability. This can happen because of required or urgent maintenance or upgrade, hardware or software failures, back-end (e.g., database) failures, etc.; in these cases the remaining web servers get too much traffic and become overloaded.
Symptoms of overload
The symptoms of an overloaded web server are:
Requests are served with (possibly long) delays (from 1 second to a few hundred seconds).
The web server returns an HTTP error code, such as 500, 502, 503, 504, 408, or even 404, which is inappropriate for an overload condition.
The web server refuses or resets (interrupts) TCP connections before it returns any content.
In very rare cases, the web server returns only a part of the requested content. This behavior can be considered a bug, even if it usually arises as a symptom of overload.
Anti-overload techniques
To partially overcome above average load limits and to prevent overload, most popular web sites use common techniques like:
Managing network traffic, by using:
Firewalls to block unwanted traffic coming from bad IP sources or having bad patterns
HTTP traffic managers to drop, redirect or rewrite requests having bad HTTP patterns
Bandwidth management and traffic shaping, in order to smooth down peaks in network usage
Deploying web cache techniques
Using different domain names to serve different (static and dynamic) content by separate web servers, i.e.:
http://images.example.com
http://www.example.com
Using different domain names and/or computers to separate big files from small and medium-sized files; the idea is to be able to fully cache small and medium-sized files and to efficiently serve big or huge (over 10 - 1000 MB) files by using different settings
Using many internet servers (programs) per computer, each one bound to its own network card and IP address
Using many internet servers (computers) that are grouped together behind a load balancer so that they act or are seen as one big web server
Adding more hardware resources (i.e. RAM, disks) to each computer
Tuning OS parameters for hardware capabilities and usage
Using more efficient computer programs for web servers, etc.
Using other workarounds, especially if dynamic content is involved
Kernel-mode and user-mode web servers
A web server can be either incorporated into the OS kernel, or in user space (like other regular applications).
An in-kernel web server (like Microsoft IIS on Windows or TUX on GNU/Linux) will usually work faster, because, as part of the system, it can directly use all the hardware resources it needs, such as non-paged memory, CPU time-slices, network adapters, or buffers.[citation needed]
Web servers that run in user-mode have to ask the system for permission to use more memory or more CPU resources. Not only do these requests to the kernel take time, but they are not always satisfied because the system reserves resources for its own usage and has the responsibility to share hardware resources with all the other running applications. Executing in user mode can also mean useless buffer copies which are another handicap for user-mode web servers.
An in-kernel web server (like Microsoft IIS on Windows or TUX on GNU/Linux) will usually work faster, because, as part of the system, it can directly use all the hardware resources it needs, such as non-paged memory, CPU time-slices, network adapters, or buffers.[citation needed]
Web servers that run in user-mode have to ask the system for permission to use more memory or more CPU resources. Not only do these requests to the kernel take time, but they are not always satisfied because the system reserves resources for its own usage and has the responsibility to share hardware resources with all the other running applications. Executing in user mode can also mean useless buffer copies which are another handicap for user-mode web servers.
Path translation
Web servers are able to map the path component of a Uniform Resource Locator (URL) into:
A local file system resource (for static requests)
An internal or external program name (for dynamic requests)
For a static request the URL path specified by the client is relative to the web server's root directory.
Consider the following URL as it would be requested by a client:
A local file system resource (for static requests)
An internal or external program name (for dynamic requests)
For a static request the URL path specified by the client is relative to the web server's root directory.
Consider the following URL as it would be requested by a client:
Common features
Virtual hosting to serve many web sites using one IP address
Large file support to be able to serve files whose size is greater than 2 GB on 32 bit OS
Bandwidth throttling to limit the speed of responses in order to not saturate the network and to be able to serve more clients
Server-side scripting to generate dynamic web pages, still keeping web server and website implementations separate from each other
Large file support to be able to serve files whose size is greater than 2 GB on 32 bit OS
Bandwidth throttling to limit the speed of responses in order to not saturate the network and to be able to serve more clients
Server-side scripting to generate dynamic web pages, still keeping web server and website implementations separate from each other
Subscribe to:
Posts (Atom)