Add HTTP method validation

[asvetlov]

No description provided.

[codecov]

Codecov Report

Merging #6533 (3720feb) into master (58da337) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #6533   +/-   ##
=======================================
  Coverage   93.36%   93.36%           
=======================================
  Files         104      104           
  Lines       30502    30509    +7     
  Branches     3067     3069    +2     
=======================================
+ Hits        28478    28485    +7     
  Misses       1850     1850           
  Partials      174      174           

Flag	Coverage Δ
unit	93.29% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
aiohttp/client_reqrep.py	98.04% <100.00%> (+0.01%)	⬆️
tests/test_client_request.py	99.57% <100.00%> (+<0.01%)	⬆️
tests/test_web_request.py	99.09% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 58da337...3720feb. Read the comment docs.

[webknjaz]

Could you use the past tense, add a trailing period and be more specific about what this validation does?

[asvetlov]

I rather recommend relaxing the 'past tense' rule. It is a spike in change-note writing, many people make this mistake.
Why should we have it? pytest accepts both present and past tenses in their changenotes.

[asvetlov]

The method validation is... the validation.
Are you asking for mentioning allowed/forbidden characters? Why?

[webknjaz]

There are several reasons for doing this:

1. Changelog has a certain audience — it's humans/end-users that need to understand what changed when updating to the given version from the previous one, hence the past tense is usually the best fit since it describes what has already happened since that previous version. While they describe a high-level effect for the end-users, they still need to be precise and include just enough context for the users to understand what they are even about without having to dig deep into the actual patch. It's different from Git commits that traditionally use the imperative mood of the present tense and focus on describing the change at hand, going deeper into internal developer-oriented details.
2. I don't think that accepting differing styles of change notes is good because this contributes to the inconsistency in the compiled things. Just look at https://docs.aiohttp.org/en/stable/changes.html#id1 — it's a zoo of styles of inconsistent phrases. Ideally, this whole list should look as if it was written by a single individual in the same consistent style.
3. It's the best guidance I can give at the moment. Unfortunately, there are not enough recommendations on the internet. But I've recently started collecting such recommendations from different sources/communities/tech writers in order to come up with better instructions for FOSS projects. I'll probably update the contributing guide at some point, once that information is discovered.

[webknjaz]

The method validation is... the validation.
Are you asking for mentioning allowed/forbidden characters? Why?

From a generic note, it seems like (1) there was no validation whatsoever and it was just added, (2) it's unclear if this is a validation of the allowed list of method names or maybe some RFC compliance implementation. It is not really clear if anything changed compared to what was in the previous version (remember that this text is disconnected from the source code and is consumed on a dedicated web page, not as a part of a PR or a Git commit or any other context).

[patchback]

Backport to 3.8: 💔 cherry-picking failed — conflicts found

❌ Failed to cleanly apply 75fca0b on top of patchback/backports/3.8/75fca0b00b4297d0a30c51ae97a65428336eb2c1/pr-6533

Backporting merged PR #6533 into master

1. Ensure you have a local repo clone of your fork. Unless you cloned it
   from the upstream, this would be your origin remote.
2. Make sure you have an upstream repo added as a remote too. In these
   instructions you'll refer to it by the name upstream. If you don't
   have it, here's how you can add it:

   $ git remote add upstream https://github.com/aio-libs/aiohttp.git

3. Ensure you have the latest copy of upstream and prepare a branch
   that will hold the backported code:

   $ git fetch upstream
   $ git checkout -b patchback/backports/3.8/75fca0b00b4297d0a30c51ae97a65428336eb2c1/pr-6533 upstream/3.8

4. Now, cherry-pick PR Add HTTP method validation #6533 contents into that branch:

   $ git cherry-pick -x 75fca0b00b4297d0a30c51ae97a65428336eb2c1

   If it'll yell at you with something like fatal: Commit 75fca0b00b4297d0a30c51ae97a65428336eb2c1 is a merge but no -m option was given., add -m 1 as follows intead:

   $ git cherry-pick -m1 -x 75fca0b00b4297d0a30c51ae97a65428336eb2c1

5. At this point, you'll probably encounter some merge conflicts. You must
   resolve them in to preserve the patch from PR Add HTTP method validation #6533 as close to the
   original as possible.
6. Push this branch to your fork on GitHub:

   $ git push origin patchback/backports/3.8/75fca0b00b4297d0a30c51ae97a65428336eb2c1/pr-6533

7. Create a PR, ensure that the CI is green. If it's not — update it so that
   the tests and any other checks pass. This is it!
   Now relax and wait for the maintainers to process your pull request
   when they have some cycles to do reviews. Don't worry — they'll tell you if
   any improvements are necessary when the time comes!

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.

[patchback]

Backport to 3.9: 💔 cherry-picking failed — conflicts found

❌ Failed to cleanly apply 75fca0b on top of patchback/backports/3.9/75fca0b00b4297d0a30c51ae97a65428336eb2c1/pr-6533

Backporting merged PR #6533 into master

1. Ensure you have a local repo clone of your fork. Unless you cloned it
   from the upstream, this would be your origin remote.
2. Make sure you have an upstream repo added as a remote too. In these
   instructions you'll refer to it by the name upstream. If you don't
   have it, here's how you can add it:

   $ git remote add upstream https://github.com/aio-libs/aiohttp.git

3. Ensure you have the latest copy of upstream and prepare a branch
   that will hold the backported code:

   $ git fetch upstream
   $ git checkout -b patchback/backports/3.9/75fca0b00b4297d0a30c51ae97a65428336eb2c1/pr-6533 upstream/3.9

4. Now, cherry-pick PR Add HTTP method validation #6533 contents into that branch:

   $ git cherry-pick -x 75fca0b00b4297d0a30c51ae97a65428336eb2c1

   If it'll yell at you with something like fatal: Commit 75fca0b00b4297d0a30c51ae97a65428336eb2c1 is a merge but no -m option was given., add -m 1 as follows intead:

   $ git cherry-pick -m1 -x 75fca0b00b4297d0a30c51ae97a65428336eb2c1

5. At this point, you'll probably encounter some merge conflicts. You must
   resolve them in to preserve the patch from PR Add HTTP method validation #6533 as close to the
   original as possible.
6. Push this branch to your fork on GitHub:

   $ git push origin patchback/backports/3.9/75fca0b00b4297d0a30c51ae97a65428336eb2c1/pr-6533

7. Create a PR, ensure that the CI is green. If it's not — update it so that
   the tests and any other checks pass. This is it!
   Now relax and wait for the maintainers to process your pull request
   when they have some cycles to do reviews. Don't worry — they'll tell you if
   any improvements are necessary when the time comes!

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.