docs/en/docs/advanced/security/http-basic-auth.md:83:At that point, by noticing that the server took some microseconds longer to send the "incorrect user or password" response, the attacker will know that she/he got _something_ right, some of the initial letters were right.
docs/en/docs/advanced/security/http-basic-auth.md:85:And then she/he can try again knowing that it's probably something more similar to `stanleyjobsox` than to `johndoe`.
docs/en/docs/advanced/security/http-basic-auth.md:89:Of course, the attacker would not try all this by hand, she/he would write a program to do it, possibly with thousands or millions of tests per second. And would get just one extra correct letter at a time.
docs/en/docs/tutorial/security/oauth2-jwt.md:23:That way, you can create a token with an expiration of, let's say, 1 week. And then when the user comes back the next day with the token, you know she/he is still logged in to your system.
docs/en/docs/tutorial/handling-errors.md:50:If the client requests `http://example.com/items/foo` (an `item_id` `"foo"`), he will receive an HTTP status code of 200, and a JSON response of:
docs/en/docs/tutorial/handling-errors.md:58:But if the client requests `http://example.com/items/bar` (a non-existent `item_id` `"bar"`), he will receive an HTTP status code of 404 (the "not found" error), and a JSON response of:
docs/en/docs/async.md:111:The cashier 💁 says something to the guy in the kitchen 👨🍳 so he knows he has to prepare your burgers 🍔 (even though he is currently preparing the ones for the previous clients).
docs/en/docs/tutorial/background-tasks.md:5:This is useful for operations that need to happen after a request, but that the client doesn't really have to be waiting for the operation to complete before receiving his response.
docs/en/docs/tutorial/security/first-steps.md:88:* The user types his `username` and `password` in the frontend, and hits `Enter`.
docs/en/docs/tutorial/response-model.md:50:In this case, it might not be a problem, because the user himself is sending the password.
docs/en/docs/async.md:151:Everyone before you is waiting 🕙 for their burgers 🍔 to be ready before leaving the counter because each of the 8 cashiers goes himself and prepares the burger right away before getting the next order.
docs/en/docs/advanced/security/http-basic-auth.md:83:At that point, by noticing that the server took some microseconds longer to send the "incorrect user or password" response, the attacker will know that she/he got _something_ right, some of the initial letters were right.
docs/en/docs/advanced/security/http-basic-auth.md:85:And then she/he can try again knowing that it's probably something more similar to `stanleyjobsox` than to `johndoe`.
docs/en/docs/advanced/security/http-basic-auth.md:89:Of course, the attacker would not try all this by hand, she/he would write a program to do it, possibly with thousands or millions of tests per second. And would get just one extra correct letter at a time.
docs/en/docs/tutorial/security/oauth2-jwt.md:23:That way, you can create a token with an expiration of, let's say, 1 week. And then when the user comes back the next day with the token, you know she/he is still logged in to your system.
You can run this yourself to get nice colourised output, with the gendered term highlighted.
It would be nice to see FastAPI use gender-inclusive language.
First check
Example
I used the following command to find a list of examples of gendered language:
The result of which was:
You can run this yourself to get nice colourised output, with the gendered term highlighted.
Description
It would be nice to see FastAPI use gender-inclusive language.
There is likely more gendered language that my
grepmissed. Better tools probably exist and can find more examples (and in languages other than English).