MQSeries.net :: View topic

goffinf · Posted: Thu Oct 25, 2012 2:08 am Post subject:

MB versions: 6.1.0.9 and 8.0.0.1

I would welcome any community experience comments for this one. We will probably raise a PMR so that we can understand v6.1 and v8 behaviours, but since these often take a while to wind thru ...

The real issue is about MB interop with Java applications around standards and RFCs (in my experience often gives rise to potential differences in interpretation). Might find that both are implemented correctly, just differently, we'll see.

There appears to be a potential issue in the way that Broker v6.1 parses multipart/related MIME messages received as a response to an HTTP Request (it might effect MQ as well â€¦ I havenâ€™t tested that).

Itsâ€™ worth noting that this issue does NOT appear in MB v8, that is v8 is able to parse the response into the Parts/Part structure.

It is hard to be certain whether MB behaviour is consistent with the relevant RFCs (see â€˜Additional Detailsâ€™ below). The fact that v6.1 and v8 behave differently suggest that they might be implementing in a more relaxed or strict way or one of them is non compliant. That said, the RFCs don't seem entirely clear.

Cause:

Broker v6.1 expects the ENDING boundary marker to be followed by a CRLF.

Effect:

If the HTTP Request node has its Response Message Parsing Domain set to â€˜MIME: For MIME wrapped data including multipartâ€™, then the response message will NOT be correctly parsed into the expected Parts/Part structure and instead will show and error â€˜Invalid Indexâ€™. Note: the node exits via the â€˜outâ€™ terminal, not â€˜failureâ€™.

Workaround:

We have a [temporary] work-around where we set the HTTP Request nodeâ€™s Response Message Parsing Domain to â€˜BLOBâ€™, and follow it with a Compute node that appends xâ€™0A0Dâ€™ and then an RCD node to reset the Domain to MIME. This works but is not ideal (and is not necessary under v

.

Additional Information:

InfoCentre says this :-

* MIME multipart boundary delimiters are represented in 7-bit ASCII. The boundary delimiter consists of a line starting with a hyphen pair, followed by a boundary string. This sequence must not occur within the MIME message at any point other than as a boundary. A MIME end-delimiter is a hyphen pair, followed by the MIME boundary string, followed by a further hyphen pair. All delimiter lines must end in the ASCII sequence <CR><LF>. An example of a delimited message is:
â€¢ --MIME_boundary
â€¢ message data
â€¢ --MIME_boundary
â€¢ message data
--MIME_boundary--

RFCs 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types (http://tools.ietf.org/html/rfc2046).

Perhaps the key part is the way that implementers may/may not support the â€˜epilogueâ€™ (data following the ending boundary marker). RFC 2046 appears to strongly suggest that this area should be â€˜ignoredâ€™ (see highlighted text below). However as the final extract shows, IF an epilogue *does* exist it is preceded by a CRLF (we are NOT receiving an epilogue).

5.1<http://tools.ietf.org/html/rfc2046#section-5.1>. Multipart Media Type 5.1.1<http://tools.ietf.org/html/rfc2046#section-5.1.1>. Common Syntax

The boundary delimiter line following the last body part is a distinguished delimiter that indicates that no further body parts will follow. Such a delimiter line is identical to the previous delimiter lines, with the addition of two more hyphens after the boundary parameter value.

--gc0pJq0M:08jU534c0p--

NOTE TO IMPLEMENTORS: Boundary string comparisons must compare the boundary value with the beginning of each candidate line. An exact match of the entire candidate line is not required; it is sufficient that the boundary appear in its entirety following the CRLF.

There appears to be room for additional information prior to the first boundary delimiter line and following the final boundary delimiter line. These areas should generally be left blank, and implementations must ignore anything that appears before the first boundary delimiter line or after the last one.

multipart-body := [preamble CRLF]
dash-boundary transport-padding CRLF
body-part *encapsulation
close-delimiter transport-padding
[CRLF epilogue]

HTTP 1.1 RFC 2616 - (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.2)

3.7.2 Multipart Types

MIME provides for a number of "multipart" types -- encapsulations of one or more entities within a single message-body. All multipart types share a common syntax, as defined in section 5.1.1 of RFC 2046

[40], and MUST include a boundary parameter as part of the media type value. The message body is itself a protocol element and MUST therefore use only CRLF to represent line breaks between body-parts. 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). These restrictions exist in order to preserve the self-delimiting nature of a multipart message- body, wherein the "end" of the message-body is indicated by the ending multipart boundary.