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

docs/howto/static-files/deployment.txt

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

docs/ref/request-response.txt

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

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

docs/releases/1.4.4.txt

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

docs/spelling_wordlist

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