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

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.

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

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:
 

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