Opened 13 months ago

Closed 8 months 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: master
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 Changed 13 months ago by timo

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

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

comment:2 Changed 8 months ago by tomchristie

  • Resolution set to wontfix
  • Status changed from new to 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.

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