Opened 40 hours ago
Last modified 12 hours ago
#36841 assigned New feature
Add multipart_parser_class attribute to HttpRequest for pluggable multipart parsing
| Reported by: | Farhan Ali | Owned by: | Farhan Ali |
|---|---|---|---|
| Component: | HTTP handling | Version: | dev |
| Severity: | Normal | Keywords: | mutipart-parsing |
| Cc: | Farhan Ali | Triage Stage: | Accepted |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Problem
Django's parse_file_upload() hardcodes MultiPartParser, making it hard
to swap in faster implementations.
Proposed Solution
As discussed with the steering council and Carlton Gibson on the forum:
- Add
multipart_parser_classclass attribute toHttpRequest(defaulting toMultiPartParser)
- Modify
parse_file_upload()to useself.multipart_parser_classinstead of direct import
- Ensure uniform parser interface:
__init__(META, input_data, upload_handlers, encoding)withparse()returning(POST, FILES)
Usage
Users can subclass HttpRequest and override multipart_parser_class to use
faster parsers.
Benefits
- Immediate performance improvements for those who need them
- Stepping stone toward DEP 17 https://github.com/django/deps/pull/88 (pluggable content type parsers)
- Minimal change
- Follows proven pattern from Django REST Framework's
parser_classes
Forum Discussion
Change History (6)
comment:1 by , 40 hours ago
| Owner: | set to |
|---|
comment:2 by , 39 hours ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:3 by , 37 hours ago
| Has patch: | set |
|---|
comment:4 by , 37 hours ago
Opened a PR https://github.com/django/django/pull/20498. But it will need a guide in the docs, I think how to use this feature properly.
comment:5 by , 34 hours ago
| Needs documentation: | set |
|---|
comment:6 by , 12 hours ago
| Needs documentation: | unset |
|---|
Note:
See TracTickets
for help on using tickets.
Thanks for opening the ticket and for following the prior discussion!
The DRF comparison is useful as prior art, but this does not add view-level
parser_classes, keeping the scope intentionally small. Configurability via a customHttpRequestsubclass is sufficient at this stage and keeps the change minimal.Proceeding with a PR along these lines sounds good, looking forward to that!