twisted.web.resource.Resource.allowedMethods doesn't determine what methods are allowed

[washort]

Resource.render only consults allowedMethods after looking for a render_ method. If a render_FOO method exists, it's invoked; allowedMethods is only used to populate the Allow header in the response.

To quote wsanchez from #3684:

OK, so with this API, if you have allowedMethods = ["GET"], then even though you are telling us that you don't want to allow HEAD (for whatever reason), we're going to ignore you and allow it anyway.

This strikes me as strangely inconsistent/exceptional API, so that bothers me. What I would prefer is that if you say allowedMethods = ["GET", "HEAD"], but you don't implement the HEAD method, then we'll use your GET implementation to provide HEAD.

That is, we should do what you ask us to do, and not pretend that we know better.

[jknight]

This doesn't seem like a bug, but rather an unfortunate attribute, and documentation that needs clarification.

The allowedMethods attribute's purpose is not to decide what methods are allowed -- render can do that by itself, I don't see why an additional filter for that is desirable.

[exarkun]

This doesn't seem like a bug, but rather an unfortunate attribute, and documentation that needs clarification.

Then maybe allowedMethods should simply not exist at all? The methods that are implemented can be discovered automatically.

[jknight]

Assuming you don't do anything crazy like have a getattr hook, yea. In web2.resource it was a method instead of an attribute, which seemed a good idea so that just in case anyone had a reason to override it, it was easily done.