Hi, why don't you simply use a base64binary field instead of an attachment? As the attachment is encoded the same way, I can't see any advantage. On top of it, attachments are notoriously tricky, especially in interop scenarios. Cheers Wolfgang
--- On Tue, 2/2/10, mhuffman <michael.mhuff...@gmail.com> wrote: > From: mhuffman <michael.mhuff...@gmail.com> > Subject: Sanity Check > To: axis-dev@ws.apache.org > Date: Tuesday, February 2, 2010, 8:58 PM > > I've written a web-service in Axis2/C based on an "Echo" > example. Based on > this this page: > > http://wso2.org/library/3618 > > I've got the echo service working with attachments. > However, I ran into a > problem using axutil_base64_decode(); it would only decode > the first 50 some > characters of the message. After some trial and error, I > figured out it was > having problems with '\r' and '\n' characters in the "char > *data"; and after > stripping out all whitespace from the character string, I > was able to decode > the attachment completely... > > I'm making a few assumptions, (1) the Pear::Soap > implementation that I'm > using to test my server is inserting the '\r\n' characters > into the mime > attachment, despite the client & server both run in a > UNIX environment (I > would imagine this is per the mime spec?); (2) AXIS2/C > doesn't contain a > function that I'm missing to strip out the line-endings > from the encoded > attachment before passing off to the decoder? > > Is this a standard way of going about decoding attachments, > or is there a > more AXIS2/C preferred (easier) way? And will/would this > work differently > with streaming? > > Thanks, > --Mike. > -- > View this message in context: > http://old.nabble.com/Sanity-Check-tp27426468p27426468.html > Sent from the Axis - Dev mailing list archive at > Nabble.com. > >
