Opened 10 years ago
Closed 10 years ago
#22797 closed New feature (wontfix)
Base Generic View `_allowed_methods` could accept request args.
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Generic views | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Currently, View._allowed_methods doesn't take into account the potential need for the request to change the availability/discover of methods, if for example the request comes with a token, cookie or whatever that grants additional method access.
_allowed_methods
is used in the base View
by the options HTTP verb and in http_method_not_allowed, both of which could pass on request, *args, **kwargs
to _allowed_methods
, and looking at GitHub's results seems to indicate that's the only place it's used. Meanwhile Sourcegraph suggests that the only real public usage (admittedly in a largely depended upon package) downstream is in Django-Rest-Framework.
Change History (2)
comment:1 by , 10 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 10 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
I'm going to recommend that we don't treat _allowed_methods
as an overridable bit of public API, or allow for the use case of dynamically altering the results for the Allow
header.
The Allow
header doesn't necessarily need to reflect which methods are actually permitted, just which are valid.
In REST framework the only thing we do with _allowed_methods
is promote it to public, read-only API.
We'd probably want to make it a public method as well.