I am going to withdraw my jira and leave what is essentially a hack in my project to support a couple of clients who can't do mtom but who must use the same service.
In our code I am going to change it to look for multipart related as well Daniel thanks for your invaluable response. I read some parts of the mtom spec and see what you were referring to. On Aug 13, 2014 12:45 AM, "Jason Pell" <[email protected]> wrote: > 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 >> >>
