Opened 7 years ago
Last modified 4 years ago
#28469 closed New feature
Add additional response type subclasses — at Version 1
| Reported by: | Adam Johnson | Owned by: | nobody |
|---|---|---|---|
| Component: | HTTP handling | Version: | 1.11 |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description (last modified by )
In the past Django has refused to add more HttpResponse subclasses to support all the codes listed in the HTTP RFC, e.g. in #9943, HttpResponseNoContent in #3362, etc.
A recent discussion on the django-developers mailing list came to the consensus that adding them would be a win. It also pointed out existing implementations in django-extras.
They should be added to Django core.
Change History (1)
comment:1 by , 7 years ago
| Description: | modified (diff) |
|---|---|
| Summary: | Add "missing" response type subclasses → Add additional response type subclasses |
| Triage Stage: | Unreviewed → Accepted |
Note:
See TracTickets
for help on using tickets.
As I mentioned on the mailing list, I don't think we should add subclasses if they don't provide any functionality besides a different status code. For that, we could document this pattern:
If a response subclass provides some other additional functionality, I'm open to adding it.