Opened 10 years ago

Closed 10 years ago

#22797 closed New feature (wontfix)

Base Generic View `_allowed_methods` could accept request args.

Reported by: Keryn Knight <django@…> 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 Tim Graham, 10 years ago

Triage Stage: UnreviewedAccepted

We'd probably want to make it a public method as well.

comment:2 by Tom Christie, 10 years ago

Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.
Back to Top