src/views/releases/v2.0.0.ejs
<h1>v<%= releaseVersion %></h1>
<p><em>I'm sorry. Did you say <strong>v2</strong>?</em></p>
<h2>Yes. v2! (It's been five years, after all)</h2>
<p><em>Oh dear. How much time is it going to take me to "upgrade" my code?</em></p>
<h2>None. v2 is 100% backwards compatible with v1</h2>
<p><em>Wait, what? Then why did you bump the major version?</em></p>
<h2>Because v2 is Yuge!</h2>
<p>This release opens all kinds of exciting doors.</p>
<p>See below for details, but there are three major reasons to upgrade.</p>
<ul class='bullet-list'>
<li>You can now create custom protocol implementations in any language of your choice.</li>
<li>The injection interface changed <em style='font-size: smaller'>(don't worry, you can
still use the old interface if you like. I'm not rude, after all).</em></li>
<li>I fixed an embarrassing security flaw in all v1 versions using
<code>--localOnly</code> and <code>--ipWhitelist</code> CLI flags.</li>
</ul>
<p class='info-icon'>Be sure to keep up with the latest releases by subscribing to the
<a href='http://mbtest.org/feed'>ATOM feed</a>.</p>
<h2>New Features</h2>
<ul class='bullet-list'>
<li>The biggest change is how protocol implementations work. In all v1 versions, they worked, but
adding a new one was difficult because of some unfortunate early design decisions. Those decisions
have been painstakingly reversed. You can now add a
<a href='//<%= host %>/docs/protocols/custom'>custom protocol</a> in any language with a very
simply API to talk back to the mountebank server. The protocol implementation will show in the logs
no differently than a built-in protocol implementation like <code>http</code>, but will be out
of process to mountebank itself. You tell mountebnak about your custom implementation with the
new <a href='//<%= host %>/docs/commandLine'><code>--protofile</code></a> command line flag.
This is Yuge!
</li>
<li>Over time, the <a href='//<%= host %>/docs/api/injection'>injection functions</a> took on new parameters.
This was unfortunate because it became
difficult to remember the order of the parameters and because there were actually two different types
of <code>state</code> parameters passed into the response injection function (I never documented one. The
documented one did not share state with predicates; the undocumented one did). While you can continue
to use the old interface, the new interface is much cleaner, accepting a single JSON parameter that
contains all relevant information. That interface now cleanly shares state between predicate and response
injection and allows for much easier evolution of injection functions (including adding async capability
to predicate injection and <a href='//<%= host %>/docs/api/behaviors#behavior-decorate'>decorate behaviors</a>).</li>
</ul>
<h2>Bug Fixes</h2>
<ul class='bullet-list'>
<li>Injection is useful but <a href='//<%= host %>/docs/security'>dangerous</a>, and you should ALWAYS take steps
to secure yourself from attackers using an injection-enabled mountebank. The easiest way to do that is with
the <a href='//<%= host %>/docs/commandLine'><code>--localOnly</code></a> CLI flag, which limits all connections
to the loopback interface (e.g., localhost). You should ALWAYS do that when running mountebank directly on your
developer machine, and use the <code>--ipWhitelist</code> flag in other scenarios.
Unfortunately, neither of these flags worked in v1. I'm sorry. That's an embarrassing security vulnerability.
They are both verified by a series of automated tests now, and verified to work with both the mountebank server itself
and all imposter sockets.
</li>
<li>The result from <code>GET /imposters/:port?replayable=true</code> now returns the value of
<code>recordRequests</code>.</li>
<li>Setting the <code>--mock</code> CLI flag no longer changes the imposter-level value of <code>recordRequests</code></li>
<li>The <code>--host</code> command line flag wasn't being reflected in the logs or mountebank URLs, and it
wasn't applying to imposters.</li>
<li>The <a href='//<%= host %>/docs/protocols/tcp'>tcp protocol page</a> took way too long to load due to page weight
(there is an embedded test on the page that required the page weight). That has been fixed.</li>
<li>The TCP proxy now respects the <a href='//<%= host %>/docs/protocols/tcp'><code>endOfRequestResolver</code></a></li>
<li>HTTP/S servers no longer time out if a <code>wait</code> behavior was set to more than about 2 minutes</li>
<li>JSON bodies with <code>nulls</code> now work with <code>copy</code> behaviors</li>
<li>SMTP now works with an empty <code>text</code> field</li>
</ul>
<h2>Contributors</h2>
<p>Many thanks to the following kind folks for help with this release, either through bug reports,
suggestions, or direct code contributions:</p>
<ul class='bullet-list'>
<li>Aleksandar "Bearclaw" Serifimoski</li>
<li>Santiago Vasquez</li>
</ul>
<h2>Install</h2>
<pre><code>npm install -g mountebank@<%= releaseVersion %></code></pre>
<p>or:</p>
<table>
<tr>
<th>Option</th>
<th>node.js required?</th>
<th>sudo required?</th>
<th>links</th>
<th>Description</th>
</tr>
<tr>
<td>Self-contained archives</td>
<td>No</td>
<td>No</td>
<td style="min-width: 5em;">
<ul>
<li><a href="https://s3.amazonaws.com/mountebank/v<%= releaseMajorMinor %>/mountebank-v<%= releaseVersion %>-darwin-x64.tar.gz">osx</a></li>
<li><a href="https://s3.amazonaws.com/mountebank/v<%= releaseMajorMinor %>/mountebank-v<%= releaseVersion %>-linux-x86.tar.gz">linux x86</a></li>
<li><a href="https://s3.amazonaws.com/mountebank/v<%= releaseMajorMinor %>/mountebank-v<%= releaseVersion %>-linux-x64.tar.gz">linux x64</a></li>
<li><a href="https://s3.amazonaws.com/mountebank/v<%= releaseMajorMinor %>/mountebank-v<%= releaseVersion %>-win-x86.zip">win x86<sup>*</sup></a></li>
<li><a href="https://s3.amazonaws.com/mountebank/v<%= releaseMajorMinor %>/mountebank-v<%= releaseVersion %>-win-x64.zip">win x64<sup>*</sup></a></li>
</ul>
</td>
<td>Simply unpack and run <code>mb</code> from inside</td>
</tr>
<tr>
<td>OS-specific packages</td>
<td>No</td>
<td>Yes</td>
<td>
<ul>
<li><a href="https://s3.amazonaws.com/mountebank/v<%= releaseMajorMinor %>/mountebank-v<%= releaseVersion %>.pkg">pkg</a></li>
<li><a href="https://s3.amazonaws.com/mountebank/v<%= releaseMajorMinor %>/mountebank-<%= releaseVersion %>-1.x86_64.rpm">rpm</a></li>
<li><a href="https://s3.amazonaws.com/mountebank/v<%= releaseMajorMinor %>/mountebank_<%= releaseVersion %>_amd64.deb">deb</a></li>
</ul>
</td>
<td>Puts <code>mb</code> at <code>/usr/local/bin</code>, which is generally in the <code>PATH</code>.</td>
</tr>
<tr>
<td>source tarball</td>
<td>Yes</td>
<td>No</td>
<td>
<ul>
<li><a href="https://s3.amazonaws.com/mountebank/v<%= releaseMajorMinor %>/mountebank-v<%= releaseVersion %>-npm.tar.gz">mb</a></li>
</ul>
</td>
<td>source tarball if you roll that way.</td>
</tr>
</table>
<h2 id='windows-path-limitations'>Windows path limitations</h2>
<p><sup>*</sup>mountebank wishes very much for your Windows experience to be hassle-free, but he is simply not qualified to address
a particular constraint of Windows Explorer. For legacy reasons, some Windows applications, including most notably Windows Explorer,
have a maximum number of characters allowed in a path of 260 characters. As mountebank writes these words, the longest path he
includes in the zip files is around 175 characters. The zip file name, which is likely to represent itself as <i>two</i>
nested directories if you use the defaults to unzip it, will be around 25 characters. That gives you very little wiggle room.
If you unzip the file in your users directory, you may very likely get an error because of this constraint.</p>
<p>The following solutions will all work:</p>
<ul class='bullet-list'>
<li>Unzip to the root of your C: drive (or a similar small path)</li>
<li>Use <a href='http://www.7-zip.org/'>7zip</a> to unzip the file instead of Windows Explorer</li>
<li>Use <code>npm</code> to install mountebank instead of the zip file</li>
</ul>