Thanks for the fast & detailed answer ! I've tried the two features ... The bad news is that I'm not in an easy position, because one feature does nothing, and the other is rejected :-(
The server (.Net absolutely not under my control), simply ignore the FastInfoset header; so I suppose this is not a supported "encoding" on their side ... And, more strange, with the gzip feature it simply rejects all my request : HTTP/1.1 400 BadRequest Connection: close Date: Fri, 14 Aug 2009 15:39:14 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET MSNSERVER: BL2MOBHGW3G07 P3P:CP="BUS CUR CONo FIN IVDo ONL OUR PHY SAMo TEL o" X-AspNet-Version: 2.0.50727 Cache-Control: private Content-Type: text/html If you (or someone else) have any other idea to preserve my bandwith, I'll be happy to read you ;-) Another precision, perhaps it could be important, my client is talking over HTTPS with the server ... Thanks again ! -- Tom Daniel Kulp a écrit : > I'm not sure much can be done in those cases. In general, most of those > cases, (headers) they are kind of built up before they are even stuck in a > soap message. You MIGHT be able to set some marshaller properties on the > JAXBDataBinding to include a JAXB NamespaceMapper thing which can be used to > prevent some of the useless namespaces from being outputted until they are > needed. That may help a bit. > > For bandwidth, though, I'd HIGHLY HIGHLY recommend turning on the FastInfoset > feature and possibly the GZIP feature. FastInfoset would shrink that message > down to easily 1/4 the size as all the strings and such are just indexed into > a table. (side affect is that it's also MUCH faster than normal soap > parsing, > also lowering CPU usage) GZIP would then compress it even more (although > that then increases CPU usage). > > See the bottom of: > http://cwiki.apache.org/CXF20DOC/features.html > for how to configure the features. See > http://cwiki.apache.org/CXF20DOC/featureslist.html > for the classnames for the GZIP and FastInfoset features. > > Note: both plugins are "negotiated" (unless you add force=true) in that > exising applications won't really change. On the first request, the CXF > client will use a normal soap message and add "Accept" type headers and if > the > feature is turned on on the server, the server will then respond back with > the > compressed forms and the client will recognize that and send subsequent > requests compressed in same. If the server doesn't see the accept headers, > it would return normal soap messages. Thus, existing clients that don't > support gzip/fastinfoset would be unaffected. > > Also note: several other SOAP clients support FastInfoset and/or GZIP. I > know Metro and Axis2 have support for FastInfoset. > > > Dan > > > > On Fri August 14 2009 5:57:13 am Thomas Sauzedde wrote: > >> Hi, >> >> First of all, I'm a happy CXF user. Everything is working perfectly ;-) >> >> On the project I'm working on I need to do some optimizations on the >> bandwidth usage. >> >> One "easy" way will be to reduce the size of the generated SOAP >> requests by removing redundant namespaces declarations. >> (I'm talking about a CXF client) >> >> In the provided sample (generated request that has been logged), is >> there a way to put all the namespaces declarations in the <Envelope> tag >> once and so avoid identical declarations below ? >> >> Thanks in advance >> >> -- >> Tom >> > >
