Hello -
We are setting up with a new trading partner who is using Sterling GIS software and are running into a few problems. We have a different trading partner who is using the same software and have been connecting with them for almost 2 years now, with no problems.
What we are seeing is that when we send them documents, the content-length header on the sync MDN is negative. The software then throws an error:
"AS2ServerRemoteImpl: Missing start boundary"
We have no problem receiving files from them (they contain the accurate content-length header).
This trading partner has emailed us the MDN and it does not contain a content-length header at all. However, when m-e-c AS2 stores the failed MDN, it shows a content-length header stored, and its value is negative. To double check at which step the negative content-length appears, we did a tcpdump to capture the MDN packets as they came over our network. The tcpdump reflects that before the MDN packets even reach m-e-c AS2, the negative content-length header appears. Our trading partner assures us that it is not coming frmo their side, however, it doesn't appear to be coming from our side either.
Have you ever heard of a problem like this before? We are currently using m-e-c AS2 build 19, have any changes been made in later builds that might address this kind of issue? After looking through the project's source code, it looks like this error isn't even triggered by a local m-e-c AS2 class, but rather from one of the MIME parsing packages.
Additionally, from our trading partner's software perspective, the documents that we send over go through perfectly fine. So another question would be, is there any downside to ignoring this problem all together, if the only negative is that there is a red square on the m-e-c AS2 gui?
Thank you for your help.
I have pasted the relevant contents of the tcpdump below.
Sending document headers:
AS2-Version: 1.1
mime-version: 1.0
User-Agent: m-e-c as2 1.0 build 19 - www.mendelson-e-c.com
recipient-address: ***********
message-id:
as2-from: DAZ
as2-to: ***********************
subject: AS2 message
from: ************
connection: close, TE
date: Wed, 22 Apr 2009 09:00:13 PDT
Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m
disposition-notification-to:**********************************
disposition-notification-options:signed-receipt-protocol=optional,pkcs7-signature;signed-receipt-micalg=optional,sha1,md5
content-disposition: attachment; filename="smime.p7m"
Host: ******************
Expect: 100-continue
Content-Length: 3163
Receiving MDN headers (look for the negative content-length header below):
Date: Wed, 22 Apr 2009 15:57:55 GMT
Server: Jetty/4.2.27 (OS/400/V5R4M0 PowerPC java/1.5.0)
Connection: close
as2-to: DAZ
as2-from: **********************
AS2-Version: 1.1
Date: Wed, 22 Apr 2009 03:58:01 GMT
message-id:
subject: Signed Message Disposition Notification
Content-Type:multipart/signed;protocol="application/pkcs7-signature";micalg=sha1;boundary="_=4543458950473662Sterling4543458950473662MOKO"
Content-Length: -392
Thanks for your help!
-daz
daz,
please update to mendelson opensource AS2 1.1 b27, this should fix the problem
Regards
Heller
Heller,
We updated to the latest build of the software, but are still having the "Missing Start Boundary" error thrown. It looks like in this version though, when it gets that error, it sends it back to the trading partner as an MDN relaying that an error occured in the receipt of the primary document.
(As a side note, it looks like this latest build still has header folding trouble in the MDN. Check in the method AS2MessagePacker::createMDN, the multiPart content-type remains folded. I haven't had a chance to test yet if it's a problem with the MimeUtility::unfold method or just the order of operations when executing MimeMessage::saveChanges. Worth a second look at least).
It seems clear to us, because of the tcpdump, that the negative content-length is coming through to us from the trading partner's side, since the packets in the tcpdump are recorded before they even get to the m-e-c as2 server on port 8080. Have you ever encountered this before? Is it possible that the trading partner is going through a proxy that adds on this negative content length. Also, the stack trace shows that the exception is thrown from the MimeMessage::parse method. I have tried to remove the content-length header from the mimemessage object before it gets to that point in the code just to see if that would help, but it did not.
Any suggestions or other places to look in the code?
Thanks!
-daz
daz,
if you have traced the whole communication, could you please send me the data to sh at mendelson dot de? I will have a look on it.
Thanks
Heller