Fixed #20330 -- Normalized spelling of "web server".

Thanks Baptiste Mispelon for the report.

django/core/handlers/base.py

@@ -237,7 +237,7 @@ def get_path_info(environ):
     """
     path_info = environ.get('PATH_INFO', str('/'))
     # Under Python 3, strings in environ are decoded with ISO-8859-1;
-    # re-encode to recover the original bytestring provided by the webserver.
+    # re-encode to recover the original bytestring provided by the web server.
     if six.PY3:
         path_info = path_info.encode('iso-8859-1')
     # It'd be better to implement URI-to-IRI decoding, see #19508.
@@ -266,7 +266,7 @@ def get_script_name(environ):
     else:
         script_name = environ.get('SCRIPT_NAME', str(''))
     # Under Python 3, strings in environ are decoded with ISO-8859-1;
-    # re-encode to recover the original bytestring provided by the webserver.
+    # re-encode to recover the original bytestring provided by the web server.
     if six.PY3:
         script_name = script_name.encode('iso-8859-1')
     # It'd be better to implement URI-to-IRI decoding, see #19508.

docs/howto/deployment/fastcgi.txt

@@ -112,7 +112,7 @@ Running a preforked server on a Unix domain socket::
 
 .. admonition:: Socket security
 
-    Django's default umask requires that the webserver and the Django fastcgi
+    Django's default umask requires that the web server and the Django fastcgi
     process be run with the same group **and** user. For increased security,
     you can run them under the same group but as different users. If you do
     this, you will need to set the umask to 0002 using the ``umask`` argument

docs/howto/static-files/index.txt

@@ -106,7 +106,7 @@ for gathering static files in a single directory so you can serve them easily.
    This will copy all files from your static folders into the
    :setting:`STATIC_ROOT` directory.
 
-3. Use a webserver of your choice to serve the
+3. Use a web server of your choice to serve the
    files. :doc:`/howto/static-files/deployment` covers some common deployment
    strategies for static files.
 

docs/intro/tutorial01.txt

@@ -123,7 +123,7 @@ These files are:
   "table of contents" of your Django-powered site. You can read more about
   URLs in :doc:`/topics/http/urls`.
 
-* :file:`mysite/wsgi.py`: An entry-point for WSGI-compatible webservers to
+* :file:`mysite/wsgi.py`: An entry-point for WSGI-compatible web servers to
   serve your project. See :doc:`/howto/deployment/wsgi/index` for more details.
 
 .. _more about packages: http://docs.python.org/tutorial/modules.html#packages

docs/ref/settings.txt

@@ -67,7 +67,7 @@ A list of strings representing the host/domain names that this Django site can
 serve. This is a security measure to prevent an attacker from poisoning caches
 and password reset emails with links to malicious hosts by submitting requests
 with a fake HTTP ``Host`` header, which is possible even under many
-seemingly-safe webserver configurations.
+seemingly-safe web server configurations.
 
 Values in this list can be fully qualified names (e.g. ``'www.example.com'``),
 in which case they will be matched against the request's ``Host`` header

docs/ref/views.txt

@@ -18,7 +18,7 @@ convenience, you'd like to have Django serve for you in local development.
 The :func:`~django.views.static.serve` view can be used to serve any directory
 you give it. (This view is **not** hardened for production use and should be
 used only as a development aid; you should serve these files in production
-using a real front-end webserver).
+using a real front-end web server).
 
 The most likely example is user-uploaded content in :setting:`MEDIA_ROOT`.
 ``django.contrib.staticfiles`` is intended for static assets and has no

docs/topics/security.txt

@@ -168,7 +168,7 @@ certain cases. While these values are sanitized to prevent Cross Site Scripting
 attacks, a fake ``Host`` value can be used for Cross-Site Request Forgery,
 cache poisoning attacks, and poisoning links in emails.
 
-Because even seemingly-secure webserver configurations are susceptible to fake
+Because even seemingly-secure web server configurations are susceptible to fake
 ``Host`` headers, Django validates ``Host`` headers against the
 :setting:`ALLOWED_HOSTS` setting in the
 :meth:`django.http.HttpRequest.get_host()` method.
@@ -181,15 +181,15 @@ For more details see the full :setting:`ALLOWED_HOSTS` documentation.
 
 .. warning::
 
-   Previous versions of this document recommended configuring your webserver to
+   Previous versions of this document recommended configuring your web server to
    ensure it validates incoming HTTP ``Host`` headers. While this is still
-   recommended, in many common webservers a configuration that seems to
+   recommended, in many common web servers a configuration that seems to
    validate the ``Host`` header may not in fact do so. For instance, even if
    Apache is configured such that your Django site is served from a non-default
    virtual host with the ``ServerName`` set, it is still possible for an HTTP
    request to match this virtual host and supply a fake ``Host`` header. Thus,
    Django now requires that you set :setting:`ALLOWED_HOSTS` explicitly rather
-   than relying on webserver configuration.
+   than relying on web server configuration.
 
 Additionally, as of 1.3.1, Django requires you to explicitly enable support for
 the ``X-Forwarded-Host`` header (via the :setting:`USE_X_FORWARDED_HOST`