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
|
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
|
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
|
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,
|
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
|
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
|
Mixing HTTP and HTTPS on the same site is discouraged, therefore
|
||||||
:meth:`~HttpRequest.build_absolute_uri()` will always generate an
|
:meth:`~HttpRequest.build_absolute_uri()` will always generate an
|
||||||
absolute URI with the same scheme the current request has. If you need
|
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.
|
all HTTP traffic to HTTPS.
|
||||||
|
|
||||||
.. method:: HttpRequest.get_signed_cookie(key, default=RAISE_ERROR, salt='', max_age=None)
|
.. 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
|
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
|
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
|
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
|
the Django application. However, it has been reported to us that even with the
|
||||||
recommended webserver configurations there are still techniques available for
|
recommended Web server configurations there are still techniques available for
|
||||||
tricking many common webservers into supplying the application with an
|
tricking many common Web servers into supplying the application with an
|
||||||
incorrect and possibly malicious Host header.
|
incorrect and possibly malicious Host header.
|
||||||
|
|
||||||
For this reason, Django 1.3.6 adds a new setting, ``ALLOWED_HOSTS``, which
|
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
|
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
|
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
|
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
|
the Django application. However, it has been reported to us that even with the
|
||||||
recommended webserver configurations there are still techniques available for
|
recommended Web server configurations there are still techniques available for
|
||||||
tricking many common webservers into supplying the application with an
|
tricking many common Web servers into supplying the application with an
|
||||||
incorrect and possibly malicious Host header.
|
incorrect and possibly malicious Host header.
|
||||||
|
|
||||||
For this reason, Django 1.4.4 adds a new setting, ``ALLOWED_HOSTS``, containing
|
For this reason, Django 1.4.4 adds a new setting, ``ALLOWED_HOSTS``, containing
|
||||||
|
|
|
@ -949,13 +949,7 @@ virtualenv
|
||||||
virtualenvs
|
virtualenvs
|
||||||
virtualized
|
virtualized
|
||||||
Votizen
|
Votizen
|
||||||
webapps
|
|
||||||
webkit
|
|
||||||
WebKit
|
|
||||||
Weblog
|
Weblog
|
||||||
webpages
|
|
||||||
webserver
|
|
||||||
webservers
|
|
||||||
whatsnext
|
whatsnext
|
||||||
whitelist
|
whitelist
|
||||||
whitelisted
|
whitelisted
|
||||||
|
|
Loading…
Reference in New Issue