On Fri April 17 2009 6:11:06 am Thomas Sauzedde wrote: > Hi everybody, > > I'm writing a CXF client for a .NET SOAP server and I'm in front of the > following issue. > I need to use MTOM but the server goes mad with my MTOM requests.
Hmm.... what version of .NET? We've tested this several times before without any issues. That said, I really don't like our boundary format. The = in there really does suck and definitely would cause issues. Having it start with --- also is not good. I've poked around a bit and I'm testing a change to make it a uuid. It would still be quoted (as per spec, that should be there), but it would look more like: boundary="uuid:e9c5f300-b0ed-4a72-b2b0-9a738e26e0a7" I'll get that committed to trunk shortly. Dan > > I'm only writing the client, the server is a remote one and I can only > try to find a workaround on the client side :-( > > From my experiments, the server is really unhappy with the way CXF names > the boundaries. > > In CXF request headers, the boundaries are like this : > Content-Type: <snip> boundary="----=_Part_0_33140442.1239893010990"; <snip> > > From CXF source code, the prefix is hardcoded and not something > configurable :-( > - > http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/ >cxf/attachment/AttachmentUtil.java - > http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/ >cxf/attachment/AttachmentSerializer.java > > I'm not a SOAP neither MTOM expert, but for sure I need the following to > make my client compatible with the server (tested with JMeter requests) > - to remove the quotes (") around the boundary name in the Content-Type > - remove the equal (=) in the boundary name > > Tu cut a long story short I need this : > > Content-Type: <snip> boundary=----_Part_0_33140442.1239893010990; <snip> > > I can of course pach my CXF installation, but I would like to stick with > "official" releases ... > > Does someone has any advices ? > > I'm thinking about an out interceptor but I'm not sure this is really > the best way to do this ... > > Regards > > -- > Tom -- Daniel Kulp [email protected] http://www.dankulp.com/blog
