Does that not seem strange. What if one particular lient cant suppport mtom but the rest can. It seems bad form to return attachments to a client that will barf on them.
In the sample interceptor I created a missing accept header or one that uses a wild card or the application/xop+xml content type will all get mtom. A client has to explicitly disable mtom with a text/xml or application/xml content type. This change is not for cxf clients but for non cxf non mtom clients. Perhaps its just better to use my interceptor locally rather than adding it to cxf. On Aug 12, 2014 11:26 PM, "Daniel Kulp" <[email protected]> wrote: > > On Aug 10, 2014, at 10:47 PM, Jason Pell <[email protected]> wrote: > > > I cant seem to find code that controls mtom based on what a client can > > handle. My understanding is the Accept header should be used. If I have a > > Accept header which is either a wild card or includes application/xop+xml > > use mtom if con figured on endpoint otherwise fall back to inlined base > 64. > > > > I tried this and it did not work. I am very surprised this is not > working. > > Perhaps I am missing something. > > The tricky part is that this would need to be disabled by default. > Nothing in any of the specs (MTOM, JAX-WS, SOAP, etc…) really allows for > any change of behavior based on the Accept header. In particular, for > JAX-WS, if MTOM is enabled on the service, we HAVE to respond with an MTOM > message no matter what the Accept header say. Also, there is no > requirement in any of those specs that we even have to set an Accept > header. Thus, many toolkits may not set it or, if they do, set it to some > generic value (like CXF always sets it to "*/*”. I just check the JAX-WS > RI and it ALWAYS sets it to "text/xml; multipart/related” (for soap 1.1) > whether MTOM is turned on on the client or not. Axis2 never sends any > Accept header at all. No idea what .NET and some of the other do. > > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > >
