Re: Controlling mtom using client headers.
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" 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" wrote: > >> >> On Aug 10, 2014, at 10:47 PM, Jason Pell 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 >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >>
Re: Controlling mtom using client headers.
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" wrote: > > On Aug 10, 2014, at 10:47 PM, Jason Pell 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 > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > >
Re: Controlling mtom using client headers.
On Aug 10, 2014, at 10:47 PM, Jason Pell 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 dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Controlling mtom using client headers.
https://issues.apache.org/jira/browse/CXF-5939 On 12/08/2014 9:07 AM, "Jason Pell" wrote: > If any other devs have info on why this is not enabled and a > recommendation for where I could add this code either to existing > interceptor or use my new one. > > I tried using this interceptor on incoming chain but seems out going > message gets properties from exchange only. > On 11/08/2014 2:22 PM, "Jason Pell" wrote: > >> In the mean time I created an interceptor to override the mtom-enabled >> property based on the Accept property. I would prefer to use something >> build into cxf, but this seems to work for my use case. >> >> >> https://github.com/pellcorp/cxf/blob/master/JavaFirst/src/main/java/com/pellcorp/server/interceptor/MtomOutInterceptor.java >> >> >> >> >> On Mon, Aug 11, 2014 at 12:47 PM, Jason Pell 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. >>> >> >>
Re: Controlling mtom using client headers.
If any other devs have info on why this is not enabled and a recommendation for where I could add this code either to existing interceptor or use my new one. I tried using this interceptor on incoming chain but seems out going message gets properties from exchange only. On 11/08/2014 2:22 PM, "Jason Pell" wrote: > In the mean time I created an interceptor to override the mtom-enabled > property based on the Accept property. I would prefer to use something > build into cxf, but this seems to work for my use case. > > > https://github.com/pellcorp/cxf/blob/master/JavaFirst/src/main/java/com/pellcorp/server/interceptor/MtomOutInterceptor.java > > > > > On Mon, Aug 11, 2014 at 12:47 PM, Jason Pell 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. >> > >
Re: Controlling mtom using client headers.
In the mean time I created an interceptor to override the mtom-enabled property based on the Accept property. I would prefer to use something build into cxf, but this seems to work for my use case. https://github.com/pellcorp/cxf/blob/master/JavaFirst/src/main/java/com/pellcorp/server/interceptor/MtomOutInterceptor.java On Mon, Aug 11, 2014 at 12:47 PM, Jason Pell 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. >
