Add first-class rate limiting support for Django views

### Code of Conduct

- [x] I agree to follow Django's Code of Conduct

### Feature Description

Add a first-class, framework-level rate limiting mechanism for standard Django views, independent of Django REST Framework.

The feature would provide a consistent way to apply request limits to views, with support for HTTP 429 responses, Retry-After headers, configurable client keys, and both synchronous and asynchronous views.

### Problem

Django currently has no general-purpose, built-in mechanism for rate limiting regular HTTP views.

Applications that need to limit repeated requests to endpoints such as login, password reset, forms, expensive operations, uploads, or application APIs currently need to rely on third-party packages, custom middleware, infrastructure-level solutions, or Django REST Framework when DRF is being used.

Django's security documentation specifically notes that Django does not throttle authentication requests and recommends using a plugin or web server module for this purpose.

This means there is no common Django-level abstraction for defining a request rate, choosing the key being limited (for example a user or client), handling exceeded limits, or supporting the same behavior consistently across synchronous and asynchronous views.

This proposal is intended as application-level request limiting and resource/abuse control. It should not be presented as a replacement for infrastructure-level DoS/DDoS protection.

### Request or proposal

proposal

### Additional Details

There is related prior work and discussion around this area:

- Django Trac #21289 discusses rate limiting specifically for authentication/login attempts.
- django-ratelimit provides a mature third-party, cache-based decorator for Django views.
- Django REST Framework provides its own throttling abstraction for API views, but this is not available to standard Django views without DRF.
- A GSoC 2026 draft proposal discussed adding native RateLimitMiddleware to Django, including sync/async support, Django's cache framework, HTTP 429 responses, and view-level decorators.
- Symfony 8.1 recently introduced declarative controller rate limiting via a #[RateLimit] attribute. This is useful prior art, although I am proposing a Django-native design rather than reproducing Symfony's API.

I originally raised this as a Django Trac ticket and was directed to the new-feature process. [Trac Ticket](https://code.djangoproject.com/ticket/37288)

I would be interested in contributing to the design and implementation if the community considers this suitable for Django core.

### Implementation Suggestions

One possible direction would be a small rate-limiting abstraction that can be applied declaratively to views.

For example:

@rate_limit("api")
def index(request):
...

or:

@rate_limit(rate="100/m", key="user")
def index(request):
...

The exact API is open for discussion.

Possible requirements could include:

- Function-based and class-based view support.
- Sync and async view support.
- Configurable rate keys, such as authenticated user, client IP, or a callable.
- Per-HTTP-method limits.
- Multiple limits on the same view, e.g. burst and sustained limits.
- Standard HTTP 429 Too Many Requests responses.
- Retry-After support where the wait time can be determined.
- A storage abstraction potentially backed by Django's cache framework.
- Clearly documented behavior under concurrency.
- Explicit handling/documentation of reverse proxies and client IP identification.
- No rate limiting enabled by default.

For example, named policies could potentially be configured centrally:

RATE_LIMITS = {
"api": {
"rate": "100/m",
"key": "user",
},
}

and referenced from views:

@rate_limit("api")
def index(request):
...

However, I don't think the proposal should prescribe the decorator/settings API before discussing whether rate limiting belongs in Django core and what abstraction would best fit Django.

An important implementation question is concurrency. Django REST Framework's current cache-based throttling documentation notes that its implementation uses non-atomic operations and may allow some additional requests under concurrent access. A Django core implementation should define its concurrency guarantees explicitly rather than accidentally promising strict limits that the configured backend cannot provide.

Start by reviewing the related Trac #21289 discussion, django-ratelimit, and Django REST Framework's throttling documentation, then compare them with the listed sync/async, cache, response, keying, and concurrency requirements. The work is complete only when the community agrees whether rate limiting belongs in Django core and defines a concrete API and behavioral guarantees.

Written by the indexing model from the issue text.