Merge branch '1.3-branch'

4 files changed, 19 insertions, 7 deletions

diff --git a/docs/api/response.rst b/docs/api/response.rst
index 8020b629a..52978a126 100644
--- a/docs/api/response.rst
+++ b/docs/api/response.rst
@@ -9,6 +9,11 @@
    :members:
    :inherited-members:
 
+.. autoclass:: FileResponse
+   :members:
+
+.. autoclass:: FileIter
+
 Functions
 ~~~~~~~~~
 
diff --git a/docs/conf.py b/docs/conf.py
index 3e38226c1..79d9946ad 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -80,7 +80,7 @@ copyright = '%s, Agendaless Consulting' % datetime.datetime.now().year
 # other places throughout the built documents.
 #
 # The short X.Y version.
-version = '1.3a8'
+version = '1.3a9'
 
 # The full version, including alpha/beta/rc tags.
 release = version
diff --git a/docs/narr/assets.rst b/docs/narr/assets.rst
index 2cc870619..22b38c929 100644
--- a/docs/narr/assets.rst
+++ b/docs/narr/assets.rst
@@ -370,19 +370,22 @@ do so, do things "by hand".  First define the view callable.
    :linenos:
 
    import os
-   from pyramid.response import Response
+   from pyramid.response import FileResponse
 
    def favicon_view(request):
        here = os.path.dirname(__file__)
-       icon = open(os.path.join(here, 'static', 'favicon.ico'), 'rb')
-       return Response(content_type='image/x-icon', app_iter=icon)
+       icon = os.path.join(here, 'static', 'favicon.ico')
+       return FileResponse(icon, request=request)
 
 The above bit of code within ``favicon_view`` computes "here", which is a
 path relative to the Python file in which the function is defined.  It then
 uses the Python ``open`` function to obtain a file handle to a file within
-"here" named ``static``, and returns a response using the open the file
-handle as the response's ``app_iter``.  It makes sure to set the right
-content_type too.
+"here" named ``static``, and returns a :class:`pyramid.response.FileResponse`
+using the file path as the response's ``path`` argument and the request as
+the response's ``request`` argument.  :class:`pyramid.response.FileResponse`
+will serve the file as quickly as possible when it's used this way.  It makes
+sure to set the right content length and content_type too based on the file
+extension of the file you pass.
 
 You might register such a view via configuration as a view callable that
 should be called as the result of a traversal:
diff --git a/docs/whatsnew-1.3.rst b/docs/whatsnew-1.3.rst
index 101caed94..daa1ffdec 100644
--- a/docs/whatsnew-1.3.rst
+++ b/docs/whatsnew-1.3.rst
@@ -354,6 +354,10 @@ Minor Feature Additions
   can be used to replace the respective default values of
   ``request.application_url`` partially.
 
+- New APIs: :class:`pyramid.response.FileResponse` and
+  :class:`pyramid.response.FileIter`, for usage in views that must serve
+  files "manually".
+
 Backwards Incompatibilities
 ---------------------------