test0908
/
django
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Normalized spelling of "Web server/page" in docs.

This commit is contained in:
Tim Graham 2016-09-29 19:51:59 -04:00
parent a09c058918
commit eb4d4376fc
5 changed files with 8 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/howto/static-files/deployment.txt
View File

@ -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

2
docs/ref/request-response.txt
View File

@ -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)

6
docs/releases/1.3.6.txt
View File

@ -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

6
docs/releases/1.4.4.txt
View File

@ -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

6
docs/spelling_wordlist
View File

@ -949,13 +949,7 @@ virtualenv
virtualenvs
virtualized
Votizen
webapps
webkit
WebKit
Weblog
webpages
webserver
webservers
whatsnext
whitelist
whitelisted