parse_multipart_form_data doesn't properly handle final boundary #489

jeffhunter opened this Issue Apr 8, 2012 · 0 comments


None yet

2 participants


parse_multipart_form_data (in assumes that either nothing or a single \r\n appears after the final form boundary. According to RFC 1341, if additional information appears after the final form boundary, it should be ignored.
"There appears to be room for additional information prior to the first encapsulation boundary and following the final boundary. These areas should generally be left blank, and implementations should ignore anything that appears before the first boundary or after the last one."

In particular, AFNetworking (an iOS library), puts two \r\n after the final boundary, which causes parse_multipart_form_data to fail.


I don't think AFNetworking really needs to do that, but it's within the bounds of the RFC.

I have worked around it by making the following change. I'm not sure if it's the best way to fix it, but it works for me:

-    if data.endswith(b("\r\n")):
-        footer_length = len(boundary) + 6
-    else:
-        footer_length = len(boundary) + 4
-    parts = data[:-footer_length].split(b("--") + boundary + b("\r\n"))
+    final_boundary_index = data.rfind(b("--") + boundary + b("--"))
+    if final_boundary_index == -1:
+        logging.warning("Invalid multipart/form-data")
+        return
+    parts = data[:final_boundary_index].split(b("--") + boundary + b("\r\n"))```
@bdarnell bdarnell closed this in e101397 May 21, 2012
@jeethu jeethu added a commit to jeethu/cyclone that referenced this issue Jun 8, 2012
@jeethu jeethu Backport fix for tornado issue #489 from tornado b51b4ae
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment