Thanks Andreas. I wanted to propose the following after reading specifications from RFC2045 to RFC2049. I thought the proposed parsing algorithm supplements existing parsing process. You being the programmer or AXIS2, you and your team have highest authority to make a final call on this. This is a proposal only.
Every header in MIME part must be terminated by <CR><LF>. In our ESB MIME case, the Content-Type header terminated with <CR><LF> but with semicolon at the end. As per my understanding (after reading spec) <CR><LF> is the key to identify next header. This is what exactly done in readHeaders() method. There is a else block which checks for the parameter ending ";" and considering the next *byte as part of the same header irrespective it is continued in the same line or next line. * What I would like to propose, because every header in MIME part always start with "Content-", it may be a good idea to check if the next byte followed by <CR><LF> starts with "Content-". *If yes, consider it as a new header not as continuation to existing header especially if the continuation is terminated by <CR><LF>. * *In this case, If the first header terminates the line with semi-colon and new line doesn't start with "Content-", consider it as continuation. Otherwise, consider it as new header and process accordingly. * ** ** *I have found few example MIME messages where a content-type is terminated with semi-colon: (In first example, content-transfer-encoding must have been parsed as part of content-type and content-id is parsed seperately. ) I have no idea which version of MIME spec they meant in those examples* ** *Example 1* http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.wsfep.multiplatform.doc/info/ae/ae/twbs_enablemtom.html ** other transport headers ... Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_0FE43E4D025F0BF3DC11582467646812; * type="application/xop+xml";* start=" <0.urn:uuid:0fe43e4d025f0bf3dc11582467646...@apache.org>"; start-info="text/xml"; charset=UTF-8 --MIMEBoundaryurn_uuid_0FE43E4D025F0BF3DC11582467646812 *content-type: application/xop+xml; charset=UTF-8; type="text/xml";* content-transfer-encoding: binary content-id: <0.urn:uuid:0fe43e4d025f0bf3dc11582467646...@apache.org> <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv=" http://schemas.xmlsoap.org/soap/envelope/";> <soapenv:Header/> <soapenv:Body> <sendImage xmlns="http://org/apache/axis2/jaxws/sample/mtom";> <input> <imageData> <xop:Include xmlns:xop=" http://www.w3.org/2004/08/xop/include"; href=" cid:1.urn:uuid:0fe43e4d025f0bf3dc11582467646...@apache.org"/> </imageData> </input> </sendImage> </soapenv:Body> </soapenv:Envelope> --MIMEBoundaryurn_uuid_0FE43E4D025F0BF3DC11582467646812 content-type: text/plain content-transfer-encoding: binary content-id: <1.urn:uuid:0fe43e4d025f0bf3dc11582467646...@apache.org> … binary data goes here … --MIMEBoundaryurn_uuid_0FE43E4D025F0BF3DC11582467646812-- ** *Example 2:* ** http://msdn.microsoft.com/en-us/library/ms526560(v=exchg.10).aspx <javascript:CodeSnippet_CopyCode('CodeSnippetContainerCode0');> From: John Doe <exam...@example.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="XXXXboundary text" This is a multipart message in MIME format. --XXXXboundary text Content-Type: text/plain this is the body text --XXXXboundary text Content-Type: text/plain; Content-Disposition: attachment; filename="test.txt" this is the attachment text --XXXXboundary text-- On Thu, May 26, 2011 at 4:00 PM, Andreas Veithen <andreas.veit...@gmail.com>wrote: > Strict interpretation of the specs would actually suggest that a > semicolon at the end of the content type is not valid. I think that > RFC 2045 applies here, which defines the syntax of the Content-Type > header as follows (see section 5.1): > > content := "Content-Type" ":" type "/" subtype > *(";" parameter) > > This means that a semicolon must be followed by a parameter. Therefore > I would say that the ESB is not entirely compliant with the MIME > specification. > > On the other hand, the code in > org.apache.axiom.attachments.impl.PartFactory interprets a semicolon > at the end of a header as a continuation character. This code was > actually introduced by AXIOM-257 [1] and went into Axiom 1.2.8 (Do you > use an Axis2 version that ships with Axiom 1.2.8 or above?). What I > don't see is which part of the specs actually defines the semicolon as > a continuation character. Somebody else recently came up with an issue > related to multi-line headers [2], and this may somehow be related. > > Andreas > > [1] https://issues.apache.org/jira/browse/AXIOM-257 > [2] http://markmail.org/thread/guj44ez5wdnxjobc > > On Thu, May 26, 2011 at 16:10, Anil Atyam <aanilku...@gmail.com> wrote: > > AXIS2 Committors- > > > > > > It appears that there may be a bug in parsing MIME body parts. I have > > downloaded the source code and included additional logging. Please see > the > > below details. > > > > Brief History: > > The first MIME header (Not Working) comes from ESB server which in turn > > invoked a web service on IIS server (.net framework). JBOSS powered by > AXIS2 > > --> ESB --> IIS > > Second MIME Header (Working) comes directly from IIS server. JBOSS > powered > > by AXIS2 --> IIS (.net Framework) > > > > I will be glad If you can confirm by running the first MIME header using > the > > tools you have to see if you can obtain the content type. There is NO > > Commercial Product involved in this particular prototype scenario. I am > > using AXIS2 downloaded from APACHE website along with source code. > > > > I do not know If this is a bug in AXIS2 Parser or the content type must > not > > have been terminated by semi colon. Appreciate if you can comment > > your expertise. You can very well ignore this question if it is out of > scope > > from open source support. > > > > > > NOT Working MIME Header (Extra logging given in getPart() Method) - > Please > > notice content-type is ending with semi-colon. I think the parser > assuming > > content-ID is part of content-type and hence part.getContentID() returned > > NULL (highlighted in RED) > > > > > > [5/25/11 16:33:51:472 EDT] 00000029 Attachments I *** getPart : > return > > part-> part.getContentID(): null part.getContentType(): > > application/xop+xml;charset=utf-8;type="text/xml";Content-ID: > > <0.634419380311847...@example.org> part.toString(): > > org.apache.axiom.attachments.impl.PartOnMemoryEnhanced@443c443c > > > > > > > > ----MIMEBoundary634419380311847897 > > > > Content-Type: application/xop+xml;type="text/xml"; > > > > Content-ID: <0.634419380311847...@example.org> > > > > content-transfer-encoding: binary > > > > > > > > Working MIME Header (Extra logging given in getPart() Method) > > > > > > [5/25/11 16:40:07:195 EDT] 00000029 Attachments I *** getPart : > return > > part-> part.getContentID(): <0.634419384069456...@example.org> > > part.getContentType(): application/xop+xml; charset=utf-8; > type="text/xml; > > charset=utf-8" part.toString(): > > org.apache.axiom.attachments.impl.PartOnMemoryEnhanced@27f427f4 > > > > > > > > ----MIMEBoundary634419384069456049 > > > > content-id: <0.634419384069456...@example.org> > > > > content-type: application/xop+xml; charset=utf-8; type="text/xml; > > charset=utf-8" > > > > content-transfer-encoding: binary > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org > For additional commands, e-mail: java-dev-h...@axis.apache.org > > -- Thanks, Anil Atyam,
