As we have seen, Python supports a wide range of http codes, including all the IANA official codes + some additional ones such as 418 (The requested entity is a teapot incapable of brewing coffee).
My point is: If python supports 418 and aims to support others, it might be reasonable to support 450 (blocked by windows parental controls). Assuming we want to cover all bases and scenarios, adding this to http and the docs could be of some use to people.
And before you answer “does anyone care about 450 that was a long time ago” Yes, people care. Some windows computers use it, and some websites now use it to indicate that they are functional but device restrictions won’t allow them to fulfill the request.
Also those who like to dig deep may have found this statement in the http docs:
I don’t even think I agree that it’s unofficial or unregistered. It is listed officially, it’s just doesn’t have a “true” meaning behind it. (which doesn’t stop people from using it)
The list of methods in http.HTTPMethods is all from one source, plus PATCH. Notably, it does not include methods used by related services such as WebDAV, which adds quite a few methods that won’t be relevant to the vast majority of HTTP users. WebDAV’s response codes are included in http.HTTPStatus though. So if you want to push for the BREW method to be added on account of 418’s presence, for consistency you should also push for PROPFIND, MKCOL, LOCK, MOVE, etc, from RFC 4918.
I don’t think we need to do that. Being able to give explanations for response codes is a lot more useful than listing every possible HTTP verb that anyone has used. Keep in mind that you can always call request() with an arbitrary method name, if you are in fact connecting to a coffeepot.
That was intended to be funny, but now thinking about it, why not? Some People might in fact find it useful to have methods such as LOCK, MOVE etc. in python. And in the event of calling request() with an arbitrary method name → Thats a messy implementation begging to be fixed.
And if we don’t want to add BREW, PROPFIND, and WHEN, isn’t our implementation of 418 a half-hearted work?
Yeah, you’re crazy. But let’s face it, most of us are, or we wouldn’t still be here.
TBH I think it’s more useful to have a translation table of potential responses than all of the possible verbs. If you’re going to attempt to BREW, or to LOCK, you’re going to need to know a lot of semantics; but if you attempt to do something on the wrong type of server, it’s useful to at least be able to translate a code into a description. From the flip side, if you’re writing a server and you get a verb you don’t know, all you have to do is return 405 and call it a night. [1] Given the enormous number of potential HTTP-adjacent verbs, it’s best to stick to a single definition of which ones are to be used, and for that, IANA’s repository seems like a good one to use.
In that case, why are we including status codes but not their respective methods? That alone should be a warning flag for inconsistency. For example, people might see that we have included 418 and subsequently try to complete a BREW request. If we want to stick to IANA’s repository, we should remove 418 and WebDAV’s response codes. What if someone tries a LOCK request thinking we support WebDAV?
Sure we can support 5 more methods if we wanted - imo it is more confusing right now than to have extra methods. And we can always document them clearly in a lookup table or whatever
Any quick google search can answer any questions people may have.
You have to admit that including something in one place but dropping its core component in the other makes no sense for this core reason
if you seriously get a 418, chances are you want to use BREW or one of the others from the rfc If we backed save418, we should have added at least the 418 methods a looong time ago
IMO yes. I was going to comment about that but decided to hold off on the moment.
Considering the situation, (and the discussion title) we may as well talk about this.
Do you all think we should add 306? I’m +1 there, and
Another question I’m going to leave to you all: what should we do about 104? I’m +0 for that because even though IANA registered it, it is temporary and is currently in beta (trial ends in November)
EDIT: I take back what I said about 306. IANA is trying to deprecate and does not recommend the use of it due to “security concerns”
There exist many unofficial codes. Since these codes are unofficial and subject to change without notice, there’s no requirement to keep track of them.
