Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the CGI CPAN distribution.

Report information
The Basics
Id: 31107
Status: rejected
Priority: 0/
Queue: CGI

People
Owner: MARKSTOS [...] cpan.org
Requestors: sebastiano.piccoli [...] staff.dada.net
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



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>
Download (untitled) / with headers
text/plain 2.4k
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/
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>
Download (untitled) / with headers
text/plain 3.8k
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/
Hello, Do you find that this issue is still reproducible with CGI.pm 3.43? Mark
Download (untitled) / with headers
text/plain 240b
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.
Download (untitled) / with headers
text/plain 1.7k
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)
Download (untitled) / with headers
text/plain 579b
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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.