summaryrefslogtreecommitdiff
path: root/docs/releases
diff options
context:
space:
mode:
Diffstat (limited to 'docs/releases')
-rw-r--r--docs/releases/1.0.txt2
-rw-r--r--docs/releases/1.1.txt2
-rw-r--r--docs/releases/1.10.txt2
-rw-r--r--docs/releases/1.11.txt2
-rw-r--r--docs/releases/1.3.6.txt6
-rw-r--r--docs/releases/1.4.4.txt6
-rw-r--r--docs/releases/1.4.txt8
-rw-r--r--docs/releases/1.9.txt2
-rw-r--r--docs/releases/2.0.txt2
9 files changed, 16 insertions, 16 deletions
diff --git a/docs/releases/1.0.txt b/docs/releases/1.0.txt
index 6db106f4d7..69c460f7b6 100644
--- a/docs/releases/1.0.txt
+++ b/docs/releases/1.0.txt
@@ -6,7 +6,7 @@ Welcome to Django 1.0!
We've been looking forward to this moment for over three years, and it's finally
here. Django 1.0 represents the largest milestone in Django's development to
-date: a Web framework that a group of perfectionists can truly be proud of.
+date: a web framework that a group of perfectionists can truly be proud of.
Django 1.0 represents over three years of community development as an Open
Source project. Django's received contributions from hundreds of developers,
diff --git a/docs/releases/1.1.txt b/docs/releases/1.1.txt
index 21040a9e24..b9d51d6b9e 100644
--- a/docs/releases/1.1.txt
+++ b/docs/releases/1.1.txt
@@ -422,7 +422,7 @@ Other new features and changes introduced since Django 1.0 include:
notably, the memcached backend -- these operations will be atomic, and
quite fast.
-* Django now can :doc:`easily delegate authentication to the Web server
+* Django now can :doc:`easily delegate authentication to the web server
</howto/auth-remote-user>` via a new authentication backend that supports
the standard ``REMOTE_USER`` environment variable used for this purpose.
diff --git a/docs/releases/1.10.txt b/docs/releases/1.10.txt
index efad6d3cd4..eaae87f6e4 100644
--- a/docs/releases/1.10.txt
+++ b/docs/releases/1.10.txt
@@ -864,7 +864,7 @@ Miscellaneous
* The WSGI handler no longer removes content of responses from ``HEAD``
requests or responses with a ``status_code`` of 100-199, 204, or 304. Most
- Web servers already implement this behavior. Responses retrieved using the
+ web servers already implement this behavior. Responses retrieved using the
Django test client continue to have these "response fixes" applied.
* ``Model.__init__()`` now receives ``django.db.models.DEFERRED`` as the value
diff --git a/docs/releases/1.11.txt b/docs/releases/1.11.txt
index 4423c3b17b..4716307526 100644
--- a/docs/releases/1.11.txt
+++ b/docs/releases/1.11.txt
@@ -741,7 +741,7 @@ Miscellaneous
to allow including lists inside help text.
* :class:`~django.middleware.http.ConditionalGetMiddleware` no longer sets the
- ``Date`` header as Web servers set that header. It also no longer sets the
+ ``Date`` header as web servers set that header. It also no longer sets the
``Content-Length`` header as this is now done by
:class:`~django.middleware.common.CommonMiddleware`.
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
diff --git a/docs/releases/1.4.4.txt b/docs/releases/1.4.4.txt
index 979d1144f3..8e6b5b287e 100644
--- a/docs/releases/1.4.4.txt
+++ b/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 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.4.4 adds a new setting, ``ALLOWED_HOSTS``, containing
diff --git a/docs/releases/1.4.txt b/docs/releases/1.4.txt
index b9430eb33f..d18061240f 100644
--- a/docs/releases/1.4.txt
+++ b/docs/releases/1.4.txt
@@ -331,7 +331,7 @@ Tools for cryptographic signing
Django 1.4 adds both a low-level API for signing values and a high-level API
for setting and reading signed cookies, one of the most common uses of
-signing in Web applications.
+signing in web applications.
See the :doc:`cryptographic signing </topics/signing>` docs for more
information.
@@ -688,14 +688,14 @@ files included in apps.
Starting in Django 1.4, the admin's static files also follow this
convention, to make the files easier to deploy. In previous versions of Django,
it was also common to define an ``ADMIN_MEDIA_PREFIX`` setting to point to the
-URL where the admin's static files live on a Web server. This setting has now
+URL where the admin's static files live on a web server. This setting has now
been deprecated and replaced by the more general setting :setting:`STATIC_URL`.
Django will now expect to find the admin static files under the URL
``<STATIC_URL>/admin/``.
If you've previously used a URL path for ``ADMIN_MEDIA_PREFIX`` (e.g.
``/media/``) simply make sure :setting:`STATIC_URL` and :setting:`STATIC_ROOT`
-are configured and your Web server serves those files correctly. The
+are configured and your web server serves those files correctly. The
development server continues to serve the admin files just like before. Read
the :doc:`static files howto </howto/static-files/index>` for more details.
@@ -719,7 +719,7 @@ admin app. Our new policy formalizes existing practices: `YUI's A-grade`_
browsers should provide a fully-functional admin experience, with the notable
exception of Internet Explorer 6, which is no longer supported.
-Released over 10 years ago, IE6 imposes many limitations on modern Web
+Released over 10 years ago, IE6 imposes many limitations on modern web
development. The practical implications of this policy are that contributors
are free to improve the admin without consideration for these limitations.
diff --git a/docs/releases/1.9.txt b/docs/releases/1.9.txt
index 241b9daec4..a12151fc80 100644
--- a/docs/releases/1.9.txt
+++ b/docs/releases/1.9.txt
@@ -591,7 +591,7 @@ Requests and Responses
* The :class:`~django.middleware.common.BrokenLinkEmailsMiddleware` now
ignores 404s when the referer is equal to the requested URL. To circumvent
- the empty referer check already implemented, some Web bots set the referer to
+ the empty referer check already implemented, some web bots set the referer to
the requested URL.
Templates
diff --git a/docs/releases/2.0.txt b/docs/releases/2.0.txt
index 5f0a17dc97..7ad0a27ed4 100644
--- a/docs/releases/2.0.txt
+++ b/docs/releases/2.0.txt
@@ -306,7 +306,7 @@ Pagination
Requests and Responses
~~~~~~~~~~~~~~~~~~~~~~
-* The :djadmin:`runserver` Web server supports HTTP 1.1.
+* The :djadmin:`runserver` web server supports HTTP 1.1.
Templates
~~~~~~~~~