mirror of https://github.com/pallets/flask.git
docs: ``Flask-Uploads``, ``X-Forwarded-Host``
This commit is contained in:
parent
06d9a5e738
commit
17eee81da0
2
CHANGES
2
CHANGES
|
@ -380,7 +380,7 @@ Version 0.6.1
|
|||
Bugfix release, released on December 31st 2010
|
||||
|
||||
- Fixed an issue where the default ``OPTIONS`` response was
|
||||
not exposing all valid methods in the `Allow` header.
|
||||
not exposing all valid methods in the ``Allow`` header.
|
||||
- Jinja2 template loading syntax now allows "./" in front of
|
||||
a template load path. Previously this caused issues with
|
||||
module setups.
|
||||
|
|
|
@ -104,8 +104,8 @@ localhost at port 8000, setting appropriate headers:
|
|||
}
|
||||
|
||||
If your httpd is not providing these headers, the most common setup invokes the
|
||||
host being set from `X-Forwarded-Host` and the remote address from
|
||||
`X-Forwarded-For`::
|
||||
host being set from ``X-Forwarded-Host`` and the remote address from
|
||||
``X-Forwarded-For``::
|
||||
|
||||
from werkzeug.contrib.fixers import ProxyFix
|
||||
app.wsgi_app = ProxyFix(app.wsgi_app)
|
||||
|
|
|
@ -144,7 +144,7 @@ Dispatch by Path
|
|||
----------------
|
||||
|
||||
Dispatching by a path on the URL is very similar. Instead of looking at
|
||||
the `Host` header to figure out the subdomain one simply looks at the
|
||||
the ``Host`` header to figure out the subdomain one simply looks at the
|
||||
request path up to the first slash::
|
||||
|
||||
from threading import Lock
|
||||
|
|
|
@ -184,7 +184,7 @@ An Easier Solution
|
|||
|
||||
Because the common pattern for file uploads exists almost unchanged in all
|
||||
applications dealing with uploads, there is a Flask extension called
|
||||
`Flask-Uploads`_ that implements a full fledged upload mechanism with
|
||||
``Flask-Uploads``_ that implements a full fledged upload mechanism with
|
||||
white and blacklisting of extensions and more.
|
||||
|
||||
.. _Flask-Uploads: http://pythonhosted.org/Flask-Uploads/
|
||||
|
|
|
@ -418,8 +418,8 @@ def send_file(filename_or_fp, mimetype=None, as_attachment=False,
|
|||
most efficient method available and configured. By default it will
|
||||
try to use the WSGI server's file_wrapper support. Alternatively
|
||||
you can set the application's :attr:`~Flask.use_x_sendfile` attribute
|
||||
to ``True`` to directly emit an `X-Sendfile` header. This however
|
||||
requires support of the underlying webserver for `X-Sendfile`.
|
||||
to ``True`` to directly emit an ``X-Sendfile`` header. This however
|
||||
requires support of the underlying webserver for ``X-Sendfile``.
|
||||
|
||||
By default it will try to guess the mimetype for you, but you can
|
||||
also explicitly provide one. For extra security you probably want
|
||||
|
@ -453,7 +453,7 @@ def send_file(filename_or_fp, mimetype=None, as_attachment=False,
|
|||
relative to the :attr:`~Flask.root_path` if a
|
||||
relative path is specified.
|
||||
Alternatively a file object might be provided
|
||||
in which case `X-Sendfile` might not work and
|
||||
in which case ``X-Sendfile`` might not work and
|
||||
fall back to the traditional method. Make sure
|
||||
that the file pointer is positioned at the start
|
||||
of data to send before calling :func:`send_file`.
|
||||
|
@ -605,7 +605,7 @@ def send_from_directory(directory, filename, **options):
|
|||
|
||||
.. admonition:: Sending files and Performance
|
||||
|
||||
It is strongly recommended to activate either `X-Sendfile` support in
|
||||
It is strongly recommended to activate either ``X-Sendfile`` support in
|
||||
your webserver or (if no authentication happens) to tell the webserver
|
||||
to serve files for the given path on its own without calling into the
|
||||
web application for improved performance.
|
||||
|
|
Loading…
Reference in New Issue