cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Pell <ja...@pellcorp.com>
Subject Re: Controlling mtom using client headers.
Date Tue, 12 Aug 2014 14:49:52 GMT
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" <jason@pellcorp.com> 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" <dkulp@apache.org> wrote:
>
>>
>> On Aug 10, 2014, at 10:47 PM, Jason Pell <jason@pellcorp.com> 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
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message