From 2135bcec61cf346555f8fd1e24bbb9267d002502 Mon Sep 17 00:00:00 2001
From: Aldo Cortesi <aldo@nullcube.com>
Date: Sun, 24 May 2015 14:09:51 +1200
Subject: docs: styles now live in www.mitproxy.org repo, make images
 responsive

---
 doc-src/howmitmproxy.html | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

(limited to 'doc-src/howmitmproxy.html')

diff --git a/doc-src/howmitmproxy.html b/doc-src/howmitmproxy.html
index 832a61a8..f114e145 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>
@@ -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">
-- 
cgit v1.2.3