summaryrefslogtreecommitdiff
path: root/docs/releases/1.3.6.txt
diff options
context:
space:
mode:
authorDavid Smith <smithdc@gmail.com>2021-07-23 07:48:16 +0100
committerMariusz Felisiak <felisiak.mariusz@gmail.com>2021-07-29 06:24:12 +0200
commit1024b5e74a7166313ad4e4975a15e90dccd3ec5f (patch)
tree05d75177f183de5e3c58dbf25a3f71ff4a5c820a /docs/releases/1.3.6.txt
parentacde91745656a852a15db7611c08cabf93bb735b (diff)
Fixed 32956 -- Lowercased spelling of "web" and "web framework" where appropriate.
Diffstat (limited to 'docs/releases/1.3.6.txt')
-rw-r--r--docs/releases/1.3.6.txt6
1 files changed, 3 insertions, 3 deletions
diff --git a/docs/releases/1.3.6.txt b/docs/releases/1.3.6.txt
index 8932939425..5d25bdacd8 100644
--- a/docs/releases/1.3.6.txt
+++ b/docs/releases/1.3.6.txt
@@ -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 Web servers 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 Web server configurations there are still techniques available for
-tricking many common Web servers 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