Merge branch 'master' into hardfailvenv

Conflicts:
	dev

1 files changed, 7 insertions, 7 deletions

diff --git a/doc-src/howmitmproxy.html b/doc-src/howmitmproxy.html
index 94afd522..fabd393a 100644
--- a/doc-src/howmitmproxy.html
+++ b/doc-src/howmitmproxy.html
@@ -26,7 +26,7 @@ This is a proxy GET request - an extended form of the vanilla HTTP GET request
 that includes a schema and host specification, and it includes all the
 information mitmproxy needs to proceed.
 
-<img src="explicit.png"/>
+<img class="img-responsive" src="explicit.png"/>
 
 <table class="table">
     <tbody>
@@ -84,7 +84,7 @@ attempts to MITM an SSL connection for analysis. Our answer to this conundrum
 is to become a trusted Certificate Authority ourselves. Mitmproxy includes a
 full CA implementation that generates interception certificates on the fly. To
 get the client to trust these certificates, we [register mitmproxy as a trusted
-CA with the device manually](@!urlTo("ssl.html")!@).
+CA with the device manually](@!urlTo("certinstall.html")!@).
 
 ## Complication 1: What's the remote hostname?
 
@@ -120,8 +120,8 @@ Name](http://en.wikipedia.org/wiki/SubjectAltName) field in the SSL certificate
 that allows an arbitrary number of alternative domains to be specified. If the
 expected domain matches any of these, the client will proceed, even though the
 domain doesn't match the certificate Common Name. The answer here is simple:
-when extract the CN from the upstream cert, we also extract the SANs, and add
-them to the generated dummy certificate.
+when we extract the CN from the upstream cert, we also extract the SANs, and
+add them to the generated dummy certificate.
 
 
 ## Complication 3: Server Name Indication
@@ -158,7 +158,7 @@ handshake. Luckily, this is almost never an issue in practice.
 
 Lets put all of this together into the complete explicitly proxied HTTPS flow.
 
-<img src="explicit_https.png"/>
+<img class="img-responsive" src="explicit_https.png"/>
 
 <table class="table">
     <tbody>
@@ -250,7 +250,7 @@ mitmproxy, this takes the form of a built-in set of
 that know how to talk to each platform's redirection mechanism.  Once we have
 this information, the process is fairly straight-forward.
 
-<img src="transparent.png"/>
+<img class="img-responsive" src="transparent.png"/>
 
 
 <table class="table">
@@ -296,7 +296,7 @@ transparently proxying HTTP, and explicitly proxying HTTPS. We use the routing
 mechanism to establish the upstream server address, and then proceed as for
 explicit HTTPS connections to establish the CN and SANs, and cope with SNI.
 
-<img src="transparent_https.png"/>
+<img class="img-responsive" src="transparent_https.png"/>
 
 
 <table class="table">