Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Fixed some unnescesarily gendered language in the docs

  • Loading branch information...
commit 4e07d93325b3989073b181e4505f2e6ed707743b 1 parent eb38257
@alex alex authored
View
4 docs/internals/git.txt
@@ -135,8 +135,8 @@ Feature-development branches
.. admonition:: Historical information
Since Django moved to Git in 2012, anyone can clone the repository and
- create his own branches, alleviating the need for official branches in the
- source code repository.
+ create their own branches, alleviating the need for official branches in
+ the source code repository.
The following section is mostly useful if you're exploring the repository's
history, for example if you're trying to understand how some features were
View
4 docs/topics/cache.txt
@@ -1027,8 +1027,8 @@ expose incorrect or sensitive data to subsequent visitors to those pages.
For example, say you operate a Web email system, and the contents of the
"inbox" page obviously depend on which user is logged in. If an ISP blindly
cached your site, then the first user who logged in through that ISP would have
-his user-specific inbox page cached for subsequent visitors to the site. That's
-not cool.
+their user-specific inbox page cached for subsequent visitors to the site.
+That's not cool.
Fortunately, HTTP provides a solution to this problem. A number of HTTP headers
exist to instruct upstream caches to differ their cache contents depending on
View
6 docs/topics/http/sessions.txt
@@ -330,7 +330,7 @@ Before version 1.6, Django defaulted to using :mod:`pickle` to serialize
session data before storing it in the backend. If you're using the :ref:`signed
cookie session backend<cookie-session-backend>` and :setting:`SECRET_KEY` is
known by an attacker (there isn't an inherent vulnerability in Django that
-would cause it to leak), the attacker could insert a string into his session
+would cause it to leak), the attacker could insert a string into their session
which, when unpickled, executes arbitrary code on the server. The technique for
doing so is simple and easily available on the internet. Although the cookie
session storage signs the cookie-stored data to prevent tampering, a
@@ -659,8 +659,8 @@ domain. This makes session fixation possible if all subdomains are not
controlled by trusted users (or, are at least unable to set cookies).
For example, an attacker could log into ``good.example.com`` and get a valid
-session for his account. If the attacker has control over ``bad.example.com``,
-he can use it to send his session key to you since a subdomain is permitted
+session for their account. If the attacker has control over ``bad.example.com``,
+they can use it to send their session key to you since a subdomain is permitted
to set cookies on ``*.example.com``. When you visit ``good.example.com``,
you'll be logged in as the attacker and might inadvertently enter your
sensitive personal data (e.g. credit card info) into the attackers account.
View
2  docs/topics/templates.txt
@@ -432,7 +432,7 @@ template fragment::
Hello, {{ name }}.
At first, this seems like a harmless way to display a user's name, but consider
-what would happen if the user entered his name as this::
+what would happen if the user entered their name as this::
<script>alert('hello')</script>
Please sign in to comment.
Something went wrong with that request. Please try again.