What are WSGI and CGI in plain English?

Question

Every time I read either WSGI or CGI I cringe. I've tried reading on it before but nothing really has stuck.

What is it really in plain English?

Does it just pipe requests to a terminal and redirect the output?

Solution 1

WSGI runs the Python interpreter on web server start, either as part of the web server process (embedded mode) or as a separate process (daemon mode), and loads the script into it. Each request results in a specific function in the script being called, with the request environment passed as arguments to the function.

CGI runs the script as a separate process each request and uses environment variables, stdin, and stdout to "communicate" with it.

Solution 2

From a totally step-back point of view, Blankman, here is my "Intro Page" for Web Server Gateway Interface:

PART ONE: WEB SERVERS

Web servers serve up responses. They sit around, waiting patiently, and then with no warning at all, suddenly:

• a client process sends a request. The client process could be a web server, a bot, a mobile app, whatever. It is simply "the client"
• the web server receives this request
• deliberate mumble various things happen (see below)
• The web server sends back something to the client
• web server sits around again

Web servers (at least, the better ones) are VERY good at this. They scale up and down processing depending on demand, they reliably hold conversations with the flakiest of clients over really cruddy networks, and we never really have to worry about it. They just keep on serving.

This is my point: web servers are just that: servers. They know nothing about content, nothing about users, nothing in fact other than how to wait a lot and reply reliably.

Your choice of web server should reflect your delivery preference, not your software. Your web server should be in charge of serving, not processing or logical stuff.

PART TWO: (PYTHON) SOFTWARE

Software does not sit around. Software only exists at execution time. Software is not terribly accommodating when it comes to unexpected changes in its environment (files not being where it expects, parameters being renamed etc). Although optimisation should be a central tenet of your design (of course), software itself does not optimise. Developers optimise. Software executes. Software does all the stuff in the 'deliberate mumble' section above. Could be anything.

Your choice or design of software should reflect your application, your choice of functionality, and not your choice of web server.

This is where the traditional method of "compiling in" languages to web servers becomes painful. You end up putting code in your application to cope with the physical server environment or, at least, being forced to choose an appropriate 'wrapper' library to include at runtime, to give the illusion of uniformity across web servers.

SO WHAT IS WSGI?

So, at last, what is WSGI? WSGI is a set of rules, written in two halves. They are written in such a way that they can be integrated into any environment that welcomes integration.

The first part, written for the web server side, says "OK, if you want to deal with a WSGI application, here's how the software will be thinking when it loads. Here are the things you must make available to the application, and here is the interface (layout) that you can expect every application to have. Moreover, if anything goes wrong, here's how the app will be thinking and how you can expect it to behave."

The second part, written for the Python application software, says "OK, if you want to deal with a WSGI server, here's how the server will be thinking when it contacts you. Here are the things you must make available to the server, and here is the interface (layout) that you can expect every server to have. Moreover, if anything goes wrong, here's how you should behave and here's what you should tell the server."

So there you have it - servers will be servers and software will be software, and here's a way they can get along just great without one having to make any allowances for the specifics of the other. This is WSGI.

mod_wsgi, on the other hand, is a plugin for Apache that lets it talk to WSGI-compliant software, in other words, mod_wsgi is an implementation - in Apache - of the rules of part one of the rule book above.

As for CGI.... ask someone else :-)

Solution 3

If you are unclear on all the terms in this space, and let's face it, it's a confusing acronym-laden one, there's also a good background reader in the form of an official python HOWTO which discusses CGI vs. FastCGI vs. WSGI and so on. I wish I'd read it first.

Solution 4

Both CGI and WSGI define standard interfaces that programs can use to handle web requests. The CGI interface is at a lower level than WSGI, and involves the server setting up environment variables containing the data from the HTTP request, with the program returning something formatted pretty much like a bare HTTP server response.

WSGI, on the other hand, is a Python-specific, slightly higher-level interface that allows programmers to write applications that are server-agnostic and which can be wrapped in other WSGI applications (middleware).

View more solutions

Comments

[MaddTheSane]

stackoverflow.com/questions/219110/…

[Graham Dumpleton]

WSGI != mod_wsgi. Your language suggest you mean mod_wsgi which is an implementation of WSGI. WSGI itself is merely a specification and can be implemented in many different ways, including on top of CGI.

[Ignacio Vazquez-Abrams]

@Graham: Are you saying that there are no other WSGI containers that support running WSGI apps in those modes?

[Graham Dumpleton]

Technically one could say there are more subtle variations than just those two, at least in as much as how the processes get started or how code gets activated within an embedded system. So one just has to be careful in generalising things into just those two categories. At a gross level you might say what you have, but there is quite a bit more to it than that if you want to delve into it.

[Mike Lee]

@GrahamDumpleton, out of curiosity, would you mind explaining how WSGI can be implemented on top of CGI?

[Graham Dumpleton]

Read the WSGI specification. It shows an example CGI/WSGI bridge. python.org/dev/peps/pep-3333/#the-server-gateway-side For a more robust implementation see github.com/GrahamDumpleton/cgi2wsgi Seriously though, in general you would want to avoid CGI.

[Bruno Bronosky]

Rather than let this answer end with "ask someone else", I wish someone would edit this answer to include CGI in the same manner.

[PirateApp]

latest version of the doc as of 2018 September docs.python.org/3.4/howto/webservers.html

[Rahul]

'servers will be servers and software will be software' - 'servers are from mars and software is from venus' :)

[huggie]

The link contains the most elaborate explanations I've found so far. However, it falls short on how to use FastCGI without WSGI, therefore stops short of explaining what WSGI is. Otherwise it was really great up til MoinMoin where it again, fell short on what WSGI really is compares to the FastCGI interface. Also the question remains for me when trying to develop without the WSGI model, whether mod_python, fastcgi both uses the traditional CGI interface. Also, even with CGI, it really didn't explain how are things communicated via stdin, stdout, env and so forth, with a CGI program.

[huggie]

Reading the Wikipedia entry on CGI and PEP3333 clears a lot of things up.