Fixed 32956 -- Lowercased spelling of "web" and "web framework" where appropriate.

8 files changed, 17 insertions, 17 deletions

diff --git a/docs/howto/auth-remote-user.txt b/docs/howto/auth-remote-user.txt
index 66c35943ba..20bd84d055 100644
--- a/docs/howto/auth-remote-user.txt
+++ b/docs/howto/auth-remote-user.txt
@@ -3,7 +3,7 @@ How to authenticate using ``REMOTE_USER``
 =========================================
 
 This document describes how to make use of external authentication sources
-(where the Web server sets the ``REMOTE_USER`` environment variable) in your
+(where the web server sets the ``REMOTE_USER`` environment variable) in your
 Django applications.  This type of authentication solution is typically seen on
 intranet sites, with single sign-on solutions such as IIS and Integrated
 Windows Authentication or Apache and `mod_authnz_ldap`_, `CAS`_, `Cosign`_,
@@ -15,7 +15,7 @@ Windows Authentication or Apache and `mod_authnz_ldap`_, `CAS`_, `Cosign`_,
 .. _WebAuth: https://uit.stanford.edu/service/authentication
 .. _mod_auth_sspi: https://sourceforge.net/projects/mod-auth-sspi
 
-When the Web server takes care of authentication it typically sets the
+When the web server takes care of authentication it typically sets the
 ``REMOTE_USER`` environment variable for use in the underlying application.  In
 Django, ``REMOTE_USER`` is made available in the :attr:`request.META
 <django.http.HttpRequest.META>` attribute.  Django can be configured to make
diff --git a/docs/howto/deployment/checklist.txt b/docs/howto/deployment/checklist.txt
index f5133185fa..7f19ac9a71 100644
--- a/docs/howto/deployment/checklist.txt
+++ b/docs/howto/deployment/checklist.txt
@@ -85,7 +85,7 @@ you use a wildcard, you must perform your own validation of the ``Host`` HTTP
 header, or otherwise ensure that you aren't vulnerable to this category of
 attacks.
 
-You should also configure the Web server that sits in front of Django to
+You should also configure the web server that sits in front of Django to
 validate the host. It should respond with a static error page or ignore
 requests for incorrect hosts instead of forwarding the request to Django. This
 way you'll avoid spurious errors in your Django logs (or emails if you have
@@ -249,5 +249,5 @@ Django includes default views and templates for several HTTP error codes. You
 may want to override the default templates by creating the following templates
 in your root template directory: ``404.html``, ``500.html``, ``403.html``, and
 ``400.html``. The :ref:`default error views <error-views>` that use these
-templates should suffice for 99% of Web applications, but you can
+templates should suffice for 99% of web applications, but you can
 :ref:`customize them <customizing-error-views>` as well.
diff --git a/docs/howto/deployment/index.txt b/docs/howto/deployment/index.txt
index c1cb6d8cd2..ef55a8dcfa 100644
--- a/docs/howto/deployment/index.txt
+++ b/docs/howto/deployment/index.txt
@@ -2,7 +2,7 @@
 Deploying Django
 ================
 
-Django is full of shortcuts to make Web developers' lives easier, but all
+Django is full of shortcuts to make web developers' lives easier, but all
 those tools are of no use if you can't easily deploy your sites. Since Django's
 inception, ease of deployment has been a major goal.
 
@@ -16,7 +16,7 @@ make that communication happen.
 
 Django currently supports two interfaces: WSGI and ASGI.
 
-* `WSGI`_ is the main Python standard for communicating between Web servers and
+* `WSGI`_ is the main Python standard for communicating between web servers and
   applications, but it only supports synchronous code.
 
 * `ASGI`_ is the new, asynchronous-friendly standard that will allow your
diff --git a/docs/howto/deployment/wsgi/modwsgi.txt b/docs/howto/deployment/wsgi/modwsgi.txt
index fa56f4ee03..e12c927cf4 100644
--- a/docs/howto/deployment/wsgi/modwsgi.txt
+++ b/docs/howto/deployment/wsgi/modwsgi.txt
@@ -131,10 +131,10 @@ mode`_.
 Serving files
 =============
 
-Django doesn't serve files itself; it leaves that job to whichever Web
+Django doesn't serve files itself; it leaves that job to whichever web
 server you choose.
 
-We recommend using a separate Web server -- i.e., one that's not also running
+We recommend using a separate web server -- i.e., one that's not also running
 Django -- for serving media. Here are some good choices:
 
 * Nginx_
@@ -189,15 +189,15 @@ When :mod:`django.contrib.staticfiles` is in :setting:`INSTALLED_APPS`, the
 Django development server automatically serves the static files of the
 admin app (and any other installed apps). This is however not the case when you
 use any other server arrangement. You're responsible for setting up Apache, or
-whichever Web server you're using, to serve the admin files.
+whichever web server you're using, to serve the admin files.
 
 The admin files live in (:file:`django/contrib/admin/static/admin`) of the
 Django distribution.
 
 We **strongly** recommend using :mod:`django.contrib.staticfiles` to handle the
-admin files (along with a Web server as outlined in the previous section; this
+admin files (along with a web server as outlined in the previous section; this
 means using the :djadmin:`collectstatic` management command to collect the
-static files in :setting:`STATIC_ROOT`, and then configuring your Web server to
+static files in :setting:`STATIC_ROOT`, and then configuring your web server to
 serve :setting:`STATIC_ROOT` at :setting:`STATIC_URL`), but here are three
 other approaches:
 
diff --git a/docs/howto/deployment/wsgi/uwsgi.txt b/docs/howto/deployment/wsgi/uwsgi.txt
index 6e66189b4e..f441d73f04 100644
--- a/docs/howto/deployment/wsgi/uwsgi.txt
+++ b/docs/howto/deployment/wsgi/uwsgi.txt
@@ -37,7 +37,7 @@ command. For example:
 uWSGI model
 -----------
 
-uWSGI operates on a client-server model. Your Web server (e.g., nginx, Apache)
+uWSGI operates on a client-server model. Your web server (e.g., nginx, Apache)
 communicates with a ``django-uwsgi`` "worker" process to serve dynamic content.
 
 Configuring and starting the uWSGI server for Django
diff --git a/docs/howto/error-reporting.txt b/docs/howto/error-reporting.txt
index 06fc434f67..a445514c98 100644
--- a/docs/howto/error-reporting.txt
+++ b/docs/howto/error-reporting.txt
@@ -64,9 +64,9 @@ not found" errors). Django sends emails about 404 errors when:
 If those conditions are met, Django will email the users listed in the
 :setting:`MANAGERS` setting whenever your code raises a 404 and the request has
 a referer. It doesn't bother to email for 404s that don't have a referer --
-those are usually people typing in broken URLs or broken Web bots. It also
+those are usually people typing in broken URLs or broken web bots. It also
 ignores 404s when the referer is equal to the requested URL, since this
-behavior is from broken Web bots too.
+behavior is from broken web bots too.
 
 .. note::
 
diff --git a/docs/howto/outputting-pdf.txt b/docs/howto/outputting-pdf.txt
index 7324039a91..79bebf1f6d 100644
--- a/docs/howto/outputting-pdf.txt
+++ b/docs/howto/outputting-pdf.txt
@@ -79,7 +79,7 @@ mention:
   :mimetype:`application/octet-stream` binary content.
 
 * When ``as_attachment=True`` is passed to ``FileResponse``, it sets the
-  appropriate ``Content-Disposition`` header and that tells Web browsers to
+  appropriate ``Content-Disposition`` header and that tells web browsers to
   pop-up a dialog box prompting/confirming how to handle the document even if a
   default is set on the machine. If the ``as_attachment`` parameter is omitted,
   browsers will handle the PDF using whatever program/plugin they've been
diff --git a/docs/howto/static-files/deployment.txt b/docs/howto/static-files/deployment.txt
index c1421d8244..49ac738b29 100644
--- a/docs/howto/static-files/deployment.txt
+++ b/docs/howto/static-files/deployment.txt
@@ -44,7 +44,7 @@ multiple web servers.
 Serving static files from a dedicated server
 --------------------------------------------
 
-Most larger Django sites use a separate Web server -- i.e., one that's not also
+Most larger Django sites use a separate web server -- i.e., one that's not also
 running Django -- for serving static files. This server often runs a different
 type of web server -- faster but less full-featured. Some common choices are:
 
@@ -75,7 +75,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 Web pages (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