diff --git a/Network/Wai.hs b/Network/Wai.hs
--- a/Network/Wai.hs
+++ b/Network/Wai.hs
@@ -39,8 +39,7 @@
     ( -- * WAI interface
       Request (..)
     , Response (..)
-    , ResponseEnumerator
-    , responseEnumerator
+    , responseSource
     , Application
     , Middleware
     , FilePart (..)
@@ -51,15 +50,17 @@
 import qualified Data.ByteString as B
 import qualified Data.ByteString.Lazy as L
 import Data.Typeable (Typeable)
-import Data.Enumerator (Enumerator, Iteratee (..), ($$), joinI, run_)
-import qualified Data.Enumerator as E
-import qualified Data.Enumerator.List as EL
-import Data.Enumerator.Binary (enumFile, enumFileRange)
-import Blaze.ByteString.Builder (Builder, fromByteString, fromLazyByteString)
+import Control.Monad.Trans.Resource (ResourceT)
+import qualified Data.Conduit as C
+import qualified Data.Conduit.List as CL
+import qualified Data.Conduit.Binary as CB
+import Blaze.ByteString.Builder (Builder, fromLazyByteString)
 import Network.Socket (SockAddr)
 import qualified Network.HTTP.Types as H
 import Data.Text (Text)
 import Data.ByteString.Lazy.Char8 () -- makes it easier to use responseLBS
+import Blaze.ByteString.Builder (fromByteString)
+import Data.Vault (Vault)
 
 -- | Information on the request sent by the client. This abstracts away the
 -- details of the underlying implementation.
@@ -94,13 +95,39 @@
   ,  pathInfo       :: [Text]
   -- | Parsed query string information
   ,  queryString    :: H.Query
+  ,  requestBody    :: C.Source IO B.ByteString
+  -- | A location for arbitrary data to be shared by applications and middleware.
+  , vault           :: Vault
   }
-  deriving (Show, Typeable)
+  deriving (Typeable)
 
+-- |
+--
+-- Some questions and answers about the usage of 'Builder' here:
+--
+-- Q1. Shouldn't it be at the user's discretion to use Builders internally and
+-- then create a stream of ByteStrings?
+--
+-- A1. That would be less efficient, as we wouldn't get cheap concatenation
+-- with the response headers.
+--
+-- Q2. Isn't it really inefficient to convert from ByteString to Builder, and
+-- then right back to ByteString?
+--
+-- A2. No. If the ByteStrings are small, then they will be copied into a larger
+-- buffer, which should be a performance gain overall (less system calls). If
+-- they are already large, then blaze-builder uses an InsertByteString
+-- instruction to avoid copying.
+--
+-- Q3. Doesn't this prevent us from creating comet-style servers, since data
+-- will be cached?
+--
+-- A3. You can force blaze-builder to output a ByteString before it is an
+-- optimal size by sending a flush command.
 data Response
     = ResponseFile H.Status H.ResponseHeaders FilePath (Maybe FilePart)
     | ResponseBuilder H.Status H.ResponseHeaders Builder
-    | ResponseEnumerator (forall a. ResponseEnumerator a)
+    | ResponseSource H.Status H.ResponseHeaders (C.Source IO Builder)
   deriving Typeable
 
 data FilePart = FilePart
@@ -108,26 +135,23 @@
     , filePartByteCount :: Integer
     } deriving Show
 
-type ResponseEnumerator a =
-    (H.Status -> H.ResponseHeaders -> Iteratee Builder IO a) -> IO a
-
-responseEnumerator :: Response -> ResponseEnumerator a
-responseEnumerator (ResponseEnumerator e) f = e f
-responseEnumerator (ResponseFile s h fp mpart) f =
-    run_ $ (maybe enumFile enumFilePart) mpart fp $$ joinI
-         $ EL.map fromByteString $$ f s h
-responseEnumerator (ResponseBuilder s h b) f = run_ $ do
-    E.yield () $ E.Chunks [b]
-    f s h
+responseSource :: Response -> (H.Status, H.ResponseHeaders, C.Source IO Builder) -- FIXME re-analyze usage of Builder
+responseSource (ResponseSource s h b) = (s, h, b)
+responseSource (ResponseFile s h fp (Just part)) =
+    (s, h, sourceFilePart part fp C.$= CL.map fromByteString)
+responseSource (ResponseFile s h fp Nothing) =
+    (s, h, CB.sourceFile fp C.$= CL.map fromByteString)
+responseSource (ResponseBuilder s h b) =
+    (s, h, CL.sourceList [b])
 
-enumFilePart :: FilePart -> FilePath -> Enumerator B.ByteString IO a
-enumFilePart (FilePart offset count) fp =
-    enumFileRange fp (Just offset) (Just count)
+sourceFilePart :: FilePart -> FilePath -> C.Source IO B.ByteString
+sourceFilePart (FilePart offset count) fp =
+    CB.sourceFileRange fp (Just offset) (Just count)
 
 responseLBS :: H.Status -> H.ResponseHeaders -> L.ByteString -> Response
 responseLBS s h = ResponseBuilder s h . fromLazyByteString
 
-type Application = Request -> Iteratee B.ByteString IO Response
+type Application = Request -> ResourceT IO Response
 
 -- | Middleware is a component that sits between the server and application. It
 -- can do such tasks as GZIP encoding or response caching. What follows is the
diff --git a/wai.cabal b/wai.cabal
--- a/wai.cabal
+++ b/wai.cabal
@@ -1,5 +1,5 @@
 Name:                wai
-Version:             0.4.3
+Version:             1.0.0
 Synopsis:            Web Application Interface.
 Description:         Provides a common protocol for communication between web applications and web servers.
 License:             BSD3
@@ -20,10 +20,11 @@
   Build-Depends:     base                      >= 4        && < 5
                    , bytestring                >= 0.9.1.4  && < 0.10
                    , blaze-builder             >= 0.2.1.4  && < 0.4
-                   , enumerator                >= 0.4.8    && < 0.5
+                   , conduit                   >= 0.1
                    , network                   >= 2.2.1.5  && < 2.4
                    , http-types                >= 0.6      && < 0.7
                    , text                      >= 0.7      && < 0.12
                    , transformers              >= 0.2.2    && < 0.3
+                   , vault                     >= 0.1      && < 0.2
   Exposed-modules:   Network.Wai
   ghc-options:       -Wall