All commit authors signed the Contributor License Agreement.

Every change to Python requires a NEWS entry.

Please, add it using the blurb_it Web app or the blurb command-line tool.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

While it's not technically a standard yet, would be good to be aware of https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-method-w-body-02.html, the QUERY method to indicate a safe method (like GET) that has a body (like POST).

This also misses any WebDAV methods, which users of Flask/Werkzeug occasionally ask about.

If someone used this type to annotate a parameter, it would prevent users from using other methods unless the annotation was str | HTTPMethod.

Also, consider the churn that will be introduced by this. I guarantee that some user of every library that uses HTTP will open issues asking for the library's methods to support these, which will then require every maintainer to evaluate whether they want to support it or keep rejecting requests to support it forever. Since all existing libraries use strings, they will have to add more complex code to accept both.

While it's not technically a standard yet, would be good to be aware of https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-method-w-body-02.html, the QUERY method to indicate a safe method (like GET) that has a body (like POST).

I think it might be better to include the QUERY method in a seperate PR since it isn't part of the http standard and might change over time.

This also misses any WebDAV methods, which users of Flask/Werkzeug occasionally ask about.

Most of the users don't really know about webDAV and it might be confusing to them to see it, since HTTPMethod is such a small enum (unlike HTTPStatus) it is very noticeable.
Do you think that it would be better to add the webDAV methods?

Also, consider the churn that will be introduced by this. I guarantee that some user of every library that uses HTTP will open issues asking for the library's methods to support these, which will then require every maintainer to evaluate whether they want to support it or keep rejecting requests to support it forever. Since all existing libraries use strings, they will have to add more complex code to accept both.

I think that libraries that don't conform to the new higher standards shouldn't stop the improvement of cpython.
New programs and libraries being developed shouldn't miss out on new features just because already existing libraries don't use these features.
Cpython influences the entire python community and it should provide the best practices for creating new programs.

Also, added documentation
I have made the requested changes; please review again

Thanks for making the requested changes!

@corona10: please review the changes made to this pull request.

Most of the users don't really know about webDAV and it might be confusing to them to see it, since HTTPMethod is such a small enum (unlike HTTPStatus) it is very noticeable.

You've named the enum HTTPMethod, but currently only represent the REST methods (and CONNECT and TRACE for some reason, even though they're probably even less common than WebDAV). From the RFC:

Additional methods, outside the scope of this specification, have been standardized for use in HTTP. All such methods ought to be registered within the "Hypertext Transfer Protocol (HTTP) Method Registry" maintained by IANA, as defined in Section 8.1.

https://www.iana.org/assignments/http-methods/http-methods.xhtml lists many more registered HTTP methods. Despite the RFC saying methods should be registered there, that's not a requirement, and in the end an HTTP method can be any string.

I think that libraries that don't conform to the new higher standards shouldn't stop the improvement in cpython.

This isn't a "higher standard", it's just a different value for the same thing. This needs to be very clearly an improvement, not just a change.

You've named the enum _HTTP_Method, but currently only represent the REST methods (and CONNECT and TRACE for some reason, even though they're probably even less common than WebDAV).

Correct me if I am wrong but WebDAV is an extension to HTTP, not actual part of the standard, CONNECT and TRACE are.
Anyway, what WebDAV methods do you think should be added?

This isn't a "higher standard", it's just a different value for the same thing. This needs to be very clearly an improvement, not just a change.

The code is more secure when using an enum, as magic strings are prone to mistypes and therefore errors,
I (and many more) also think that they are more convenient than just using strings.
So a more secure and convenient way to write code isn't a higher standard?

Convenient maybe, but it requires an import and a longer reference to type, compared to a string. Secure no. Mistypes of http methods result in 405 errors, not security issues.

Convenient maybe, but it requires an import and a longer reference to type, compared to a string. Secure no. Mistypes of http methods result in 405 errors, not security issues.

Secure is not the right word, I meant less bugs

I would appreciate your response

Sorry, I'm not a cpython maintainer. Some of them are at a PyCon sprint right now so I'm sure their notifications are overflowing more than usual.

@cibofo instead of merging main into your branch, rebase your branch.

@ethanfurman Done

@cibofo Please create a new PR that addes the other 31 or so registered methods. Thanks!

@ethanfurman You got it! gonna work on it tomorrow

instead of merging main into your branch, rebase your branch.

That is contrary to usual workflow: https://devguide.python.org/pullrequest/

instead of merging main into your branch, rebase your branch.

That is contrary to usual workflow: https://devguide.python.org/pullrequest/

Huh. Git Bootcamp uses rebase, although for older PRs. The couple times I tried merging in main it was a disaster, but I was also learning how to use git and github, so it could have easily been something else.

I'll keep using rebase for my own work -- it makes me happy. :-)