You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by fahman_dude <fa...@hotmail.com> on 2010/02/24 15:15:15 UTC
Oneway MEP and fastInfoset without 'force'
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
--
View this message in context: http://old.nabble.com/Oneway-MEP-and-fastInfoset-without-%27force%27-tp27714213p27714213.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Oneway MEP and fastInfoset without 'force'
Posted by Daniel Kulp <dk...@apache.org>.
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
dkulp@apache.org
http://www.dankulp.com/blog