docs: minor formatting/cleanups

2 files changed, 13 insertions, 39 deletions

diff --git a/docs/conf.py b/docs/conf.py
index ae657435..54a353ac 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -1,37 +1,8 @@
-# -*- coding: utf-8 -*-
-#
-# mitmproxy documentation build configuration file, created by
-# sphinx-quickstart on Thu Sep 03 14:04:13 2015.
-#
-# This file is execfile()d with the current directory set to its
-# containing dir.
-#
-# Note that not all possible configuration values are present in this
-# autogenerated file.
-#
-# All configuration values have a default; values that are commented out
-# serve to show the default.
-
 import sys
 import os
-import shlex
-
-# If extensions (or modules to document with autodoc) are in another directory,
-# add these directories to sys.path here. If the directory is relative to the
-# documentation root, use os.path.abspath to make it absolute, like shown here.
 sys.path.insert(0, os.path.abspath('..'))
-
 import netlib.version
 
-# -- General configuration ------------------------------------------------
-
-# If your documentation needs a minimal Sphinx version, state it here.
-#needs_sphinx = '1.0'
-
-# Add any Sphinx extension module names here, as strings. They can be
-# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
-# ones.
-
 extensions = [
     'sphinx.ext.autodoc',
     'sphinx.ext.doctest',
@@ -61,7 +32,7 @@ master_doc = 'index'
 
 # General information about the project.
 project = u'mitmproxy docs'
-copyright = u'2015, the mitmproxy project'
+copyright = u'2016, the mitmproxy project'
 author = u'The mitmproxy project'
 
 # The version info for the project you're documenting, acts as replacement for
diff --git a/mitmproxy/protocol/__init__.py b/mitmproxy/protocol/__init__.py
index b99b55bd..5bf259ae 100644
--- a/mitmproxy/protocol/__init__.py
+++ b/mitmproxy/protocol/__init__.py
@@ -1,8 +1,9 @@
 """
-In mitmproxy, protocols are implemented as a set of layers, which are composed on top each other.
-The first layer is usually the proxy mode, e.g. transparent proxy or normal HTTP proxy. Next,
-various protocol layers are stacked on top of each other - imagine WebSockets on top of an HTTP
-Upgrade request. An actual mitmproxy connection may look as follows (outermost layer first):
+In mitmproxy, protocols are implemented as a set of layers, which are composed
+on top each other. The first layer is usually the proxy mode, e.g. transparent
+proxy or normal HTTP proxy. Next, various protocol layers are stacked on top of
+each other - imagine WebSockets on top of an HTTP Upgrade request. An actual
+mitmproxy connection may look as follows (outermost layer first):
 
     Transparent HTTP proxy, no TLS:
       - TransparentProxy
@@ -16,13 +17,15 @@ Upgrade request. An actual mitmproxy connection may look as follows (outermost l
       - TLSLayer
       - WebsocketLayer (or TCPLayer)
 
-Every layer acts as a read-only context for its inner layers (see :py:class:`Layer`). To communicate
-with an outer layer, a layer can use functions provided in the context. The next layer is always
-determined by a call to :py:meth:`.next_layer() <mitmproxy.proxy.RootContext.next_layer>`,
+Every layer acts as a read-only context for its inner layers (see
+:py:class:`Layer`). To communicate with an outer layer, a layer can use
+functions provided in the context. The next layer is always determined by a
+call to :py:meth:`.next_layer() <mitmproxy.proxy.RootContext.next_layer>`,
 which is provided by the root context.
 
-Another subtle design goal of this architecture is that upstream connections should be established
-as late as possible; this makes server replay without any outgoing connections possible.
+Another subtle design goal of this architecture is that upstream connections
+should be established as late as possible; this makes server replay without any
+outgoing connections possible.
 """
 
 from __future__ import absolute_import, print_function, division