diff options
| author | David Smith <smithdc@gmail.com> | 2021-07-23 07:48:16 +0100 |
|---|---|---|
| committer | Mariusz Felisiak <felisiak.mariusz@gmail.com> | 2021-07-29 06:24:12 +0200 |
| commit | 1024b5e74a7166313ad4e4975a15e90dccd3ec5f (patch) | |
| tree | 05d75177f183de5e3c58dbf25a3f71ff4a5c820a /docs/releases/1.3.6.txt | |
| parent | acde91745656a852a15db7611c08cabf93bb735b (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.txt | 6 |
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 |
