#16201 closed Bug (fixed)
When Content-Length is 0, MultiPartParser violates RFC2616
| Reported by: | asd | Owned by: | nobody |
|---|---|---|---|
| Component: | HTTP handling | Version: | 1.3-rc |
| Severity: | Normal | Keywords: | http multipart |
| Cc: | Anand Kumria | Triage Stage: | Ready for checkin |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
RFC 2616 says that: "Any Content-Length greater than or equal to zero is a valid value." http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13
Currently MultiPartParser doesn't handle "Content-Length: 0".
The patch I've attached returns an empty request.POST in MultiPartParser.parser() if the "Content-Length: 0" instead of raising an exception on
MultiPartParser.__init__() .
I've also added the tests for this particular case in requests/tests.
( ./runtests.py --settings=test_sqlite requests.RequestsTests.test_POST_multipart_with_content_length_zero )
Attachments (1)
Change History (5)
by , 14 years ago
| Attachment: | multipartparser_content_length_0.diff added |
|---|
comment:1 by , 14 years ago
| Cc: | added |
|---|---|
| Needs documentation: | set |
| Summary: | MultiPartParser doesn't handle RFC2616 conform HTTP POST with Content-Length == 0 → When Content-Length is 0, MultiPartParser violates RFC2616 |
| Triage Stage: | Unreviewed → Accepted |
I think the patch is fine, but it probably needs something mentioned in the release notes since we are changing a low-level content-length handling thing.
comment:2 by , 14 years ago
| Needs documentation: | unset |
|---|---|
| Triage Stage: | Accepted → Ready for checkin |
The change being proposed here makes Django's HTTP implementation RFC compliant -- content-length == 0 is explicitly given as an allowed length. The fact that we have historically rejected content-length == 0 is a bug, not something that needs to be document.
patch for multipartparser bug