09.11.2016 Views

Foundations of Python Network Programming 978-1-4302-3004-5

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

CHAPTER 11 ■ WEB APPLICATIONS<br />

the WSGI standard specifies its behavior rather than its inheritance tree (duck typing).The Standard<br />

Library includes two other HTTP servers:<br />

• CGIHTTPServer takes the SimpleHTTPServer and, instead <strong>of</strong> just serving static files<br />

<strong>of</strong>f <strong>of</strong> the disk, it adds the ability to run CGI scripts (which we will cover in the next<br />

section).<br />

• SimpleXMLRPCServer and DocXMLRPCServer each provide a server endpoint against<br />

which client programs can make XML-RPC remote procedure calls, as<br />

demonstrated in Chapter 18 and Listing 22-1. This protocol uses XML files<br />

submitted through HTTP requests.<br />

Note that none <strong>of</strong> the preceding servers is typically intended for production use; instead, they are<br />

useful for small internal tasks for which you just need a quick HTTP endpoint to be used by other<br />

services internal to a system or subnet. And while most <strong>Python</strong> web frameworks will provide a way to run<br />

your application from the command line for debugging, most follow the lead <strong>of</strong> Django in<br />

recommending against using the development platform for debugging.<br />

However, a few <strong>Python</strong> web frameworks exist that not only provide their own built-in HTTP servers,<br />

but have also worked on their security and performance, so that they can be recommended for use in<br />

production.<br />

These pure-<strong>Python</strong> web servers can be very useful if you are writing an application that users will be<br />

installing locally, and you want to provide a web interface without having to ship a separate web server<br />

like Apache or nginx. Frameworks that <strong>of</strong>fer a pure-<strong>Python</strong> integrated web server include CherryPy;<br />

Zope, and thus Grok and BFG; web2py; and web.py.<br />

CGI<br />

When the first experiments were taking place with dynamically generated web pages, developers would<br />

write an external program and have their web server run the program every time a matching HTTP<br />

request arrived. This resembled the behavior <strong>of</strong> the traditional inetd server (Chapter 7), which could run<br />

an external command to answer each incoming TCP or UDP connection on a listening socket.<br />

Many <strong>of</strong> these early web servers lacked the ability to designate entire sections <strong>of</strong> a web site as<br />

dynamic; for example, you could not tell them, “all URLs beneath /cart should be handled by my<br />

application.” Instead, scripts were simply designated as a new type <strong>of</strong> content, and then placed right<br />

next to static pages, images, and archive files in directories that were already browsable from the web.<br />

Just as servers had been told that .html files should be delivered as text/html content and that .jpg files<br />

should be returned as images, they were now told that executable .cgi files should be run and their<br />

output returned to the HTTP client.<br />

Obviously, a calling convention was necessary, and so the Common Gateway Interface (CGI) was<br />

defined. It allowed programs in all sorts <strong>of</strong> languages—C, the various Unix shells, awk, Perl, <strong>Python</strong>, PHP,<br />

and so forth—to be partners in generating dynamic content.<br />

Today, the design <strong>of</strong> CGI is considered something <strong>of</strong> a disaster. Running a new process from scratch<br />

is just about the most expensive single operation that you can perform on a modern operating system,<br />

and requiring that this take place for every single incoming HTTP request is simply madness. You should<br />

avoid CGI under all circumstances. But it is possible you might someday have to connect <strong>Python</strong> code to<br />

a legacy HTTP server that does not support at least FastCGI or SCGI, so I will outline CGI's essential<br />

features.<br />

Three standard lines <strong>of</strong> communication that already existed between parent and child processes on<br />

Unix systems were used by web servers when invoking a CGI script:<br />

193

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!