Ebook Foundations of python network progra2ming (3rd edition): Part 1

Part 2 book "Foundations of python network programmin" includes content: HTTP servers, the world wide web, building and parsing E-Mail, SMTP, POP, IMAP, telnet and SSH, FTP, RPC.
Nội dung trích xuất từ tài liệu:
Ebook Foundations of python network progra2ming (3rd edition): Part 1 Chapter 10 HTTP Servers How can a Python program run as a server responding to HTTP requests? In Chapter 7, you learned several basic socket and concurrency patterns for writing a TCP-based network server. With HTTP, it is unlikely that you will ever need to write anything that low-level because the protocol’s popularity has resulted in off-the-shelf solutions for all of the major server patterns that you might need. While this chapter will focus on third-party tools, the Standard Library does have an HTTP server implementation built in. It can even be invoked from the command line.   $ python3 -m http.server Serving HTTP on 0.0.0.0 port 8000 ...   This server follows the old conventions established in the 1990s for serving up files from the filesystem. The path in the HTTP request is translated into a path to search in the local filesystem. The server is designed to serve files only at or beneath its current working directory. Files are served normally. When a directory is named, the server returns either the content of its index.html file if one exists or a dynamically generated listing of the files inside. Having a small web server available wherever Python is installed has gotten me out of more than one awkward fix over the years when I have needed to transfer files between machines and none of the more specific file transfer protocols have been available. But what are the steps to take if you need something more—if you need to put your own software in charge of responding to HTTP requests? This book tackles this question in two separate chapters. This chapter will look at server architecture and deployment, answering the questions that need solutions whether your code returns documents or a programmer- facing API. Chapter 11 will then describe the World Wide Web, and it will examine tools specific to returning HTML pages and interacting with a user’s browser. WSGI In the earliest days of HTTP programming, many Python services were written as simple CGI scripts that were invoked once per incoming request. The server carved the HTTP request into pieces and made them available to the CGI script in its environment variables. Python programmers could either inspect these directly and print an HTTP response to standard output or get help from the cgi module in the Standard Library. Launching a new process for every incoming HTTP request imposed a significant limitation on server performance, so language runtimes began implementing HTTP servers of their own. Python gained its http.server Standard Library module, which invites programmers to implement their services by adding do_GET() and do_POST() methods to their own subclass of BaseHTTPRequestHandler. 169 www.it-ebooks.info Chapter 10 ■ HTTP Servers Other programmers wanted to serve dynamic pages from a web server that could also serve static content, such as images and stylesheets. So, mod_python was written: an Apache module that allowed properly registered Python functions to provide custom Apache handlers that could provide authentication, logging, and content. The API was unique to Apache. Handlers written in Python received a special Apache request object as their argument and could call special functions in the apache module to interact with the web server. Applications that used mod_python bore little resemblance to those written against either CGI or http.server. This situation meant that each HTTP application written in Python tended to be anchored to one particular mechanism for interfacing with the web server. A service written for CGI would need, at the very least, a partial rewrite to work with http.server, and both would need modification before they could run under Apache. This made Python web services difficult to migrate to new platforms. The community responded with PEP 333, the Web Server Gateway Interface (WSGI). As David Wheeler famously said, “All problems in computer science can be solved by another level of indirection,” and the WSGI standard created the extra level of indirection that was necessary for a Python HTTP service to interoperate with any web server. It specified a calling convention that, if implemented for all major web servers, would allow both low-level services and full web frameworks to be plugged into any web server that they wanted to use. The effort to implement WSGI everywhere succeeded quickly, and it is now the standard way for Python to speak HTTP. The standard defines a WSGI application as a callable that takes two arguments. An example is shown in Listing 10-1, where the callable is a simple Python function. (Other possibilities would be a Python class, which is another kind of callable, or even class instance with a __call__() method.) The first parameter, environ, receives a dictionary that provides an extended version of the old familiar CGI set of environment variables. The second parameter is itself a callable, conventionally named start_response(), with which the WSGI app should declare its response headers. After it has been called, the app either can begin yielding byte strings (if it is itself a generator) or can return an iterable that yields byte strings when iterated across (returning a simple Python list is sufficient, for example). Listing 10-1.  A Simple HTTP Service Written as a WSGI Client #!/usr/bin/env python3 # Foundations of Python Network Programming, Third Edition # https://github.com/brandon-rhodes/fopnp/blob/m/py3/chapter10/wsgi_env.py # A simple HTTP service built directly against the low-level WSGI spec.   from pprint import pformat from wsgiref.simple_server import make_server   def app(environ, start_response): h ...