mirror of https://github.com/django/django.git
Normalized spelling of "Web server/page" in docs.
This commit is contained in:
parent
a09c058918
commit
eb4d4376fc
|
@ -117,7 +117,7 @@ Serving static files from a cloud service or CDN
|
|||
Another common tactic is to serve static files from a cloud storage provider
|
||||
like Amazon's S3 and/or a CDN (content delivery network). This lets you
|
||||
ignore the problems of serving static files and can often make for
|
||||
faster-loading webpages (especially when using a CDN).
|
||||
faster-loading Web pages (especially when using a CDN).
|
||||
|
||||
When using these services, the basic workflow would look a bit like the above,
|
||||
except that instead of using ``rsync`` to transfer your static files to the
|
||||
|
|
|
@ -305,7 +305,7 @@ Methods
|
|||
Mixing HTTP and HTTPS on the same site is discouraged, therefore
|
||||
:meth:`~HttpRequest.build_absolute_uri()` will always generate an
|
||||
absolute URI with the same scheme the current request has. If you need
|
||||
to redirect users to HTTPS, it's best to let your webserver redirect
|
||||
to redirect users to HTTPS, it's best to let your Web server redirect
|
||||
all HTTP traffic to HTTPS.
|
||||
|
||||
.. method:: HttpRequest.get_signed_cookie(key, default=RAISE_ERROR, salt='', max_age=None)
|
||||
|
|
|
@ -16,10 +16,10 @@ Host header poisoning
|
|||
Some parts of Django -- independent of end-user-written applications -- make
|
||||
use of full URLs, including domain name, which are generated from the HTTP Host
|
||||
header. Django's documentation has for some time contained notes advising users
|
||||
on how to configure webservers to ensure that only valid Host headers can reach
|
||||
on how to configure Web servers to ensure that only valid Host headers can reach
|
||||
the Django application. However, it has been reported to us that even with the
|
||||
recommended webserver configurations there are still techniques available for
|
||||
tricking many common webservers into supplying the application with an
|
||||
recommended Web server configurations there are still techniques available for
|
||||
tricking many common Web servers into supplying the application with an
|
||||
incorrect and possibly malicious Host header.
|
||||
|
||||
For this reason, Django 1.3.6 adds a new setting, ``ALLOWED_HOSTS``, which
|
||||
|
|
|
@ -17,10 +17,10 @@ Host header poisoning
|
|||
Some parts of Django -- independent of end-user-written applications -- make
|
||||
use of full URLs, including domain name, which are generated from the HTTP Host
|
||||
header. Django's documentation has for some time contained notes advising users
|
||||
on how to configure webservers to ensure that only valid Host headers can reach
|
||||
on how to configure Web servers to ensure that only valid Host headers can reach
|
||||
the Django application. However, it has been reported to us that even with the
|
||||
recommended webserver configurations there are still techniques available for
|
||||
tricking many common webservers into supplying the application with an
|
||||
recommended Web server configurations there are still techniques available for
|
||||
tricking many common Web servers into supplying the application with an
|
||||
incorrect and possibly malicious Host header.
|
||||
|
||||
For this reason, Django 1.4.4 adds a new setting, ``ALLOWED_HOSTS``, containing
|
||||
|
|
|
@ -949,13 +949,7 @@ virtualenv
|
|||
virtualenvs
|
||||
virtualized
|
||||
Votizen
|
||||
webapps
|
||||
webkit
|
||||
WebKit
|
||||
Weblog
|
||||
webpages
|
||||
webserver
|
||||
webservers
|
||||
whatsnext
|
||||
whitelist
|
||||
whitelisted
|
||||
|
|
Loading…
Reference in New Issue