A breakdown of my learnings on WSGI: Part 2

One of the things that confused me the most about this code block.

def simple_app(environ, start_response):
 “””Simplest possible application object”””
 status = ‘200 OK’
 response_headers = [(‘Content-type’, ‘text/plain’)]
 start_response(status, response_headers)
 return [‘Hello world!\n’]
class AppClass:
 “””Produce the same output, but using a class
(Note: ‘AppClass’ is the “application” here, so calling it
 returns an instance of ‘AppClass’, which is then the iterable
 return value of the “application callable” as required by
 the spec.
If we wanted to use *instances* of ‘AppClass’ as application
 objects instead, we would have to implement a ‘__call__’
 method, which would be invoked to execute the application,
 and we would need to create an instance for use by the
 server or gateway.
def __init__(self, environ, start_response):
 self.environ = environ
 self.start = start_response
def __iter__(self):
 status = ‘200 OK’
 response_headers = [(‘Content-type’, ‘text/plain’)]
 self.start(status, response_headers)
 yield “Hello world!\n”

…was the use of the environ parameter, I’d had no memorable exposure to it before this exercise and as a result, was pretty confused by it and its use. It turns out it has it’s roots in a thing called CGI , with CGI relying heavily on the meta-variables conjured up by our good old friend HTTP, and in fact, if you go even further, you’ll find that the HTTP refers to C code. As I dug deeper into CGI and also HTTP, the purpose of CGI really dawned on me.

CGI is the Common Gateway Interface, a web protocol in which HTTP is leveraged to provide more structured and reliable serving of web requests. Effecively, CGI utlises the structure of HTTP requests to serve dynamic application traffic via regular HTTP web requests.

HTTP is one of the older protocols, and also, one of the ones web developers work with the most, yet I can honestly admit that my knowledge of it is absymal. For something that provides much of the backbone to what we do as developers, I find this disconcerting.

HTTP was originally RFC’d in 1997 by Tim Berners Lee in RFC 2068. By that time, HTTP seemed fairly tried and tested, having been in use primarily by this new technology being referred to as the World Wide Web. From RFC2068 we recieved RFC2616 in 1999 and then more recently RFC7230 obseleted RFC2616 in 2014. HTTP/2, the most recent iteration, is currently supported by many browsers, with W3 estimating that 13.7% of the top 10 million websites currently support HTTP/2. And pretty much every major browser having supported it by the end of 2015. HTTP/2 was represented via RFC in 7540, in mid 2015. However, it is important to highlight that 7540 is only a proposed standard, it is not currently an Internet Standard (stamped, sealed and verified to be the most widely accepted and best regarded version/implemenation of itself).

RFC’s pertaining to most recent updates to the HTTP protocol are contained in RFC7230–7235

In my next post, I will be talking more about the internals of HTTP, and how I’ve gone about breaking it down into bits I can understand, I did mention that this is going to be a long series, and the more I dig, the more I uncover. I enjoy going from first principles, so for me, the best way to learn something is bottom up. I also would prefer to keep these short and sweet, it’s easier to write them with some type of structure, and minimise waffle.

Like what you read? Give Louis Willcock a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.