Ticket #648 (enhancement)
Opened 2 years ago
Last modified 1 year ago
Flash 8 upload socket timeout
Status: closed (fixed)
| Reported by: | fumanchu | Assigned to: | fumanchu |
|---|---|---|---|
| Priority: | normal | Milestone: | 3.1 |
| Component: | CherryPy code | Keywords: | |
| Cc: |
Flash 8's FileReference.upload(url) uses a corner-case of the multipart-MIME spec; its last part doesn't end in a trailing "\r\n" as most do. This causes cgi's read_lines_to_outerboundary to get stuck in a loop until the socket times out. See user reports here and here.
Although portions of RFC 2046 seem to imply that the last CRLF is mandatory, the BNF for multipart-body clearly shows that a trailing CRLF is optional:
multipart-body := [preamble CRLF]
dash-boundary transport-padding CRLF
body-part *encapsulation
close-delimiter transport-padding
[CRLF epilogue]
Attachments
Change History
01/26/07 21:39:44: Modified by fumanchu
- attachment flash8.patch added.
01/26/07 21:41:04: Modified by fumanchu
- status changed from new to assigned.
The attached patch (to 2.2.1) demonstrates, fixes, and tests the issue. Is this worth applying to SVN?
01/27/07 12:31:33: Modified by lawouach
Section 3.7.2 of RFC 2616 says:
Unlike in RFC 2046, the epilogue of any multipart message MUST be empty; HTTP applications MUST NOT transmit the epilogue (even if the original multipart contains an epilogue)
I'm not sure how to interpret it though in our case.
06/22/07 02:44:33: Modified by fumanchu
- status changed from assigned to closed.
- resolution set to fixed.
- milestone set to 3.1.
Added to trunk in [1678].
Patch to 2.2.1 which tests and fixes the multipart-MIME with no trailing CRLF problem