Bug #31107 for CGI: Needs Confirmation: 400 Bad request (malformed multipart POST) with multipart/related

Fri Nov 30 11:22:25 2007 sebastiano.piccoli [...] staff.dada.net - Ticket created

CC:	lstein [...] cshl.edu
Subject:	400 Bad request (malformed multipart POST) with multipart/related
Date:	Fri, 30 Nov 2007 17:20:18 +0100
To:	bug-CGI.pm [...] rt.cpan.org
From:	Sebastiano Piccoli <sebastiano.piccoli [...] staff.dada.net>

Hi, since the version 3.27 it seems that a posted multipart/related data generates the error: 400 Bad request (malformed multipart POST) I have parsed the content with MIME::Parser and it's ok. It seems that the function readHeader in read_multipart_related returns a void hash. Below the POST (------=_Part_0.7772611529786723.1196412625897 is the first line): ------=_Part_0.7772611529786723.1196412625897 Content-Type: text/xml Content-Transfer-Encoding: 7bit Content-ID: <mm7-submit> <?xml version="1.0" encoding="UTF-8" ?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header> <mm7:TransactionID env:mustUnderstand="1" xmlns:mm7="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0">4401196412625869430</mm7:TransactionID> </env:Header> <env:Body> <mm7:CapabilityASReplyReq xmlns:mm7="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0"> <MM7Version>5.3.0</MM7Version> <SenderAddress>XXXXX</SenderAddress> <CapRequestId>4401196412625869430</CapRequestId> <TimeStamp>2007-11-30 09:50:25</TimeStamp> <StatusCode>1000</StatusCode> <StatusText>Request Received</StatusText> <Content href="cid:generic_content_id"/> </mm7:CapabilityASReplyReq> </env:Body> </env:Envelope> ------=_Part_0.7772611529786723.1196412625897 Content-Type: application/x-zip; name=capabilities.zip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=capabilities.zip Content-ID: <capabilities.zip> UEsDBBQACAAIA ------=_Part_0.7772611529786723.1196412625897-- and a bash script to post it: ********************************************************** #!/bin/sh lwp-request -m 'post' -c 'multipart/related; boundary="----=_Part_0.7772611529786723.1196412625897"; type="text/xml"; start="cid:mm7-submit"' 'http://urltest.local.com/cgi-bin/my.cgi' < post.txt ********************************************************** Just to version 3.25 the same content was pushed in POSTDATA. Thanks -- Sebastiano Piccoli Software developer Dada SpA sebastiano.piccoli@staff.dada.net http://www.dada.net/

Mon Dec 03 11:25:52 2007 sebastiano.piccoli [...] staff.dada.net - Correspondence added

CC:	lstein [...] cshl.edu
Subject:	[rt.cpan.org #31107] AutoReply: 400 Bad request (malformed multipart POST) with multipart/related
Date:	Mon, 03 Dec 2007 17:23:45 +0100
To:	bug-CGI.pm [...] rt.cpan.org
From:	Sebastiano Piccoli <sebastiano.piccoli [...] staff.dada.net>

Hi Lincoln, I reply to my question. I think the issue is in the CRLF sequence. I'm using Linux Ubuntu. In particular if I set : local($CRLF) = "\012"; in sub readHeader, CGI works and my "parts are available as uploads with the Content-ID as the key". This behavior is changed: before we got the content in the param POSTDATA. A very important question: is it possible to keep _also_ the old behavior and let the content of the POST in the param POSTDATA. Only I expect to find _also_ the exact POST made somewhere. Thanks, Sebastiano Bugs in CGI.pm via RT wrote: Show quoted text

> Greetings, > > This message has been automatically generated in response to the > creation of a trouble ticket regarding: > "400 Bad request (malformed multipart POST) with multipart/related", > a summary of which appears below. > > There is no need to reply to this message right now. Your ticket has been > assigned an ID of [rt.cpan.org #31107]. Your ticket is accessible > on the web at: > > http://rt.cpan.org/Ticket/Display.html?id=31107 > > Please include the string: > > [rt.cpan.org #31107] > > in the subject line of all future correspondence about this issue. To do so, > you may reply to this message. > > Thank you, > bug-CGI.pm@rt.cpan.org > > ------------------------------------------------------------------------- > Hi, > > since the version 3.27 it seems that a posted multipart/related data > generates the error: > > 400 Bad request (malformed multipart POST) > > I have parsed the content with MIME::Parser and it's ok. It seems that > the function readHeader in read_multipart_related returns a void hash. > > Below the POST (------=_Part_0.7772611529786723.1196412625897 is the > first line): > > ------=_Part_0.7772611529786723.1196412625897 > Content-Type: text/xml > Content-Transfer-Encoding: 7bit > Content-ID: <mm7-submit> > > <?xml version="1.0" encoding="UTF-8" ?> > <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> > <env:Header> > <mm7:TransactionID env:mustUnderstand="1" > xmlns:mm7="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0">4401196412625869430</mm7:TransactionID> > </env:Header> > <env:Body> > <mm7:CapabilityASReplyReq > xmlns:mm7="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0"> > <MM7Version>5.3.0</MM7Version> > <SenderAddress>XXXXX</SenderAddress> > > <CapRequestId>4401196412625869430</CapRequestId> > <TimeStamp>2007-11-30 09:50:25</TimeStamp> > <StatusCode>1000</StatusCode> > <StatusText>Request Received</StatusText> > <Content href="cid:generic_content_id"/> > </mm7:CapabilityASReplyReq> > </env:Body> > </env:Envelope> > ------=_Part_0.7772611529786723.1196412625897 > Content-Type: application/x-zip; name=capabilities.zip > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; filename=capabilities.zip > Content-ID: <capabilities.zip> > > UEsDBBQACAAIA > ------=_Part_0.7772611529786723.1196412625897-- > > and a bash script to post it: > > ********************************************************** > #!/bin/sh > > lwp-request -m 'post' -c 'multipart/related; > boundary="----=_Part_0.7772611529786723.1196412625897"; type="text/xml"; > start="cid:mm7-submit"' 'http://urltest.local.com/cgi-bin/my.cgi' < post.txt > ********************************************************** > > Just to version 3.25 the same content was pushed in POSTDATA. > > Thanks > >

-- Sebastiano Piccoli Software developer Dada SpA sebastiano.piccoli@staff.dada.net http://www.dada.net/

Sat Jul 25 15:14:28 2009 MARKSTOS [...] cpan.org - Taken

Sat Jul 25 15:14:42 2009 MARKSTOS [...] cpan.org - Subject changed from '400 Bad request (malformed multipart POST) with multipart/related' to 'Needs Confirmation: 400 Bad request (malformed multipart POST) with multipart/related'

Sat Jul 25 15:15:35 2009 MARKSTOS [...] cpan.org - Correspondence added

Hello, Do you find that this issue is still reproducible with CGI.pm 3.43? Mark

Sat Jul 25 15:15:39 2009 The RT System itself - Status changed from 'new' to 'open'

Sat Nov 20 15:56:52 2010 MARKSTOS [...] cpan.org - Reference by ticket #62446 added

Thu May 22 08:03:19 2014 LEEJO [...] cpan.org - Correspondence added

This issue has been copied to: https://github.com/leejo/CGI.pm/issues/53 please take all future correspondence there. This ticket will remain open but please do not reply here. This ticket will be closed when the github issue is dealt with.

Fri May 23 14:28:02 2014 The RT System itself - Queue changed from CGI.pm to CGI

Wed Jun 18 16:51:02 2014 LEEJO [...] cpan.org - Correspondence added

Rejecting, there is nothing to do here. Your multipart headers *MUST* contain the CRLF. Test case added with the above examples to confirm. If you remove the line feed characters you will see the upload break with "400 bad request headers" error. commit fed3f145c5e5d13485ef57a2eccb9e08bf009e95 Author: Lee Johnson <lee@givengain.ch> Date: Wed Jun 18 22:36:44 2014 +0200 resolve #53 [rt.cpan.org #31107] - test case for multipart data sending xml content. there is nothing to do here, if you post multipart form data you MUST include CRLF in the boundary delimiters as this is part of the protocol. see the following RFC: http://www.ietf.org/rfc/rfc2046.txt note the potentially misleading part in section 5.1.1: "NOTE: The CRLF preceding the boundary delimiter line is conceptually attached to the boundary so that it is possible to have a part that does not end with a CRLF (line break)." but when one reads the BNF, we notice this isn't always true: dash-boundary := "--" boundary ; boundary taken from the value of ; boundary parameter of the ; Content-Type field. multipart-body := [preamble CRLF] dash-boundary transport-padding CRLF body-part *encapsulation close-delimiter transport-padding [CRLF epilogue] encapsulation := delimiter transport-padding CRLF body-part delimiter := CRLF dash-boundary wherein we see that the first MIME multipart dash-boundary doesn't include a CRLF. irrespective of the above, we are to spec and your MIME headers must include CRLF (well, unless you're on VMS)

Wed Jun 18 16:51:03 2014 LEEJO [...] cpan.org - Status changed from 'open' to 'rejected'

Wed Jun 18 17:01:29 2014 LEEJO [...] cpan.org - Correspondence added

Just an addendum, MIME::Parser explicitly states that its parsing logic goes beyond the RFC, this is why you can parse your original message with that module but not CGI.pm: ---- Fuzzing of CRLF and newline on input RFC 2045 dictates that MIME streams have lines terminated by CRLF (C<"\r\n">). However, it is extremely likely that folks will want to parse MIME streams where each line ends in the local newline character C<"\n"> instead. An attempt has been made to allow the parser to handle both CRLF and newline-terminated input. --- This will not be added to CGI.pm

Bug #31107 for CGI: Needs Confirmation: 400 Bad request (malformed multipart POST) with multipart/related

Preferred bug tracker