Merge pull request #196 from lazamar/patch-1

Fix typo

blog/2011/1/announcing-warp.html

@@ -52,7 +52,7 @@ <h3 id="responsefile">ResponseFile</h3>
 <p>ResponseFile which has a status code, a list of response headers and a filepath. We provide this in WAI so backends like Warp can provide an optimization by calling sendfile.</p>
 <p>We start off by sending the response headers using toLazyByteString and sendMany. This forces all of the data to be pulled into memory and then uses a vectored IO call. In general, this would be a bad move memory-wise; however, since we are only sending headers, which should be small, it's OK.</p>
 <p>We next call hasBody. I'll explain its usage here, and then pretend it doesn't exist for the other two constructors. In HTTP, there are two ways (that I'm aware of) for a response to be required to have no body: a response to a HEAD request, and a 204 response. In these cases, we simply send headers and finish.</p>
-<p>We we <em>do</em> have a response body, we call sendFile, which uses a system call to send the entire contents of the file in one system call. Next we determine <strong>keep-alive</strong>. Keep-alive allows us to reuse a connection for multiple requests. It depends on how we send the response body. There are four ways a response body can be sent:</p>
+<p>When we <em>do</em> have a response body, we call sendFile, which uses a system call to send the entire contents of the file in one system call. Next we determine <strong>keep-alive</strong>. Keep-alive allows us to reuse a connection for multiple requests. It depends on how we send the response body. There are four ways a response body can be sent:</p>
 <ul><li><p>No body at all, as mentioned above. In this case, keep-alive works.</p></li>
 <li><p>A response body with a content-length. In this case, the client knows precisely how many bytes to read after the response headers before it can expect a new response, so keep-alive works.</p></li>
 <li><p>A chunked response body. Chunked responses were an added feature of HTTP 1.1. They work well when you don't know the full size of a response before sending it. Instead, you send chunks, each with a header giving its size, followed by a 0-header. This 0-header indicates the end of a response, so the client knows to wait for the next response. Therefore, keep-alive works.</p></li>
@@ -78,4 +78,4 @@ <h3 id="responseenumerator">ResponseEnumerator</h3>
 <h2 id="conclusion">Conclusion</h2>
 <p>Well, that's the whole web server. I think that over all it's still fairly high-level. Some of the lower-level bits (takeHeaders, for instance) can be factored out into some helper libraries so that other packages can also take advantage of these highly optimized iteratees.</p>
 <p>I've hoped for a long time that as a community we can start to rally around WAI so the community's different web frameworks can work together to create great middleware, servers, and interfaces. I hope that Warp demonstrates that not only is WAI nice theoretically, it also provides an incredibly efficient interface for creating fast web servers, and therefore fast applications.</p>
-<p>If anyone has questions about the Warp code, or how to use WAI from an application side, let me know. I would love to get more frameworks to be able to take advantage of Warp and all the other tools that go along with WAI.</p>
+<p>If anyone has questions about the Warp code, or how to use WAI from an application side, let me know. I would love to get more frameworks to be able to take advantage of Warp and all the other tools that go along with WAI.</p>