From 1024b5e74a7166313ad4e4975a15e90dccd3ec5f Mon Sep 17 00:00:00 2001 From: David Smith Date: Fri, 23 Jul 2021 07:48:16 +0100 Subject: Fixed 32956 -- Lowercased spelling of "web" and "web framework" where appropriate. --- docs/releases/1.0.txt | 2 +- docs/releases/1.1.txt | 2 +- docs/releases/1.10.txt | 2 +- docs/releases/1.11.txt | 2 +- docs/releases/1.3.6.txt | 6 +++--- docs/releases/1.4.4.txt | 6 +++--- docs/releases/1.4.txt | 8 ++++---- docs/releases/1.9.txt | 2 +- docs/releases/2.0.txt | 2 +- 9 files changed, 16 insertions(+), 16 deletions(-) (limited to 'docs/releases') 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 ` 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 ` 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 ``/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 ` 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 ~~~~~~~~~ -- cgit v1.3