The bug is PROBABLY that a Content-Type is being returned with the 202 Accepted. Most likely, that shouldn't be done.
Does the client send ALL subsequent requests as text/xml or just the next one at which point it adds the Accept header and the server responds with FI? Dan On Wed February 24 2010 9:15:15 am fahman_dude wrote: > Hello, > > I am not sure if this is actually cxf relevant or just the way how Oneway > MEP and fastInfoset work, but I observed this: > > If a fastInfoset (accept=application/fastinfoset) @Oneway Message is sent > to the Server and 'force' option of the fastInfoset is not set to 'true', > the server would give 202 response and would use content-type: text/xml > like this: > > 15:04:33,000 DEBUG [main] cxf.transport.http.HTTPConduit (2132) - > Header fields: > null: [HTTP/1.1 202 Accepted] > Content-Length: [0] > Content-Type: [text/xml] > Server: [Jetty(6.1.21)] > > I am not sure if this is the consequence of server answering with text/xml, > but as a result the client issues all of the following requests with > text/xml aswell instead of switching to application/fastinfoset. > > Per definition fastinfoset works like this: > 1. client requests server with content-type:text/xml but indicates that it > (client) accept:application/fastinfoset; > 2. server responds with content-type:application/fastinfoset > 3. all the following requests from client to server will be with > content-type:application/fastinfoset > > I have successfully tested this with Twoway MEP Message and was quite > suprized as I just noticed that client does not use application/fastinfoset > anymore since I changed my message to be Oneway. > > Any comments on this would be appretiated. > > cheers > reinis -- Daniel Kulp [email protected] http://www.dankulp.com/blog
