With SOAPUI, I sometimes get a normal response with all the data, and other times I get an empty result set, using the same request parameters in the WireShark case. I only attached the one packet in the wireshark dump (for brevity sake), but I am also seeing an error "Checksum: 0xb763 [incorrect, should be 0xcc2d (maybe caused by "TCP checksum offload"?)]". Not sure what that's all about. If you write me privately, I'll give you the wsdl address so you can run SOAPUI tests. Ron
________________________________ From: Benson Margulies [mailto:[email protected]] Sent: Sat 2/21/2009 2:08 PM To: [email protected] Subject: Re: CXF 2.1 to CXF 2.2 OK, I'm confused. The non-xml log files look fine to me when I just read them into an editor. Wireshark says 'invalid text', but it mostly it is just truncating. I see <ns2:id><ns2:com, and then it stops. It looks more like the server truncated than that anyone injected trash. I see this with the 'follow TCP stream' option which dumps the entire session. What we're really crying here is for a way to make a CXF client reject this. There's nothing on our client side that would paper-over junk in the stream. Can you help me see the trash in the PacketBytes or RawTCP files? I can't help wondering if Flex is confused about content length. On Sat, Feb 21, 2009 at 3:45 PM, Benson Margulies <[email protected]> wrote: > And a dumb question: I assume that this is just as visible in SOAPui > as it is in WireShark. > > On Sat, Feb 21, 2009 at 3:44 PM, Benson Margulies <[email protected]> > wrote: >> Ron, >> >> I think you might have slightly misread me. What I meant to say was, >> 'sorry, I didn't see that you posted those logs or I would have looked >> at this again sooner.' >> >> I will be trying again to make a repro for this inside the CXF test >> framework that will permit me or someone to track this down. >> >> --benson >> >> >> On Sat, Feb 21, 2009 at 3:20 PM, Ron Grimes <[email protected]> wrote: >>> Benson, >>> >>> I have attached a wireshark dump to the JIRA at >>> https://issues.apache.org/jira/browse/CXF-1956 >>> <https://issues.apache.org/jira/browse/CXF-1956> . It isolates the packet >>> in question and should show conclusively that the problem is how CXF is >>> generating the SOAP envelope. Please note that this was run on the Tomcat >>> server and shows the response from the server address (10.0.8.13) to my >>> client address (75....). If you open the ws_dump_20090221.pcap file and >>> navigate to the Packet Details panel, and then expand the "extensible >>> Markup Language" node, you will notice how it shows a "[ ERROR: >>> Unrecognized text ] " after the id node. >>> >>> The funny thing is, as I originally reported, it generally returns this >>> exact same data correctly on the first web service request, but somehow >>> screws it up on the second, third, etc. I do notice that, in this case, the >>> garbage is appended after the id node, which would be the GuestCommentId >>> entity in relation to the GuestComment entity. Because it sometimes returns >>> this exact same record just fine, and other times not, it rules out that >>> the node element genuinely contains bad data within the database. >>> >>> Please let me know if I can provide anything further to verify that this is >>> a CXF problem or not. >>> >>> Thanks, >>> >>> Ron Grimes >>> >>> >>> ________________________________ >>> >>> From: Benson Margulies [mailto:[email protected]] >>> Sent: Sat 2/21/2009 12:20 PM >>> To: [email protected] >>> Subject: Re: CXF 2.1 to CXF 2.2 >>> >>> >>> >>> Ron, >>> >>> I missed your last addition to this bug offering concrete evidence. >>> Somehow we have to come up with a reproduction of this that we can >>> work with. >>> >>> --benson >>> >>> >>> >>> On Sat, Feb 21, 2009 at 2:03 PM, Ron Grimes <[email protected]> wrote: >>>> If you're going to develop with Flex and CXF, there are some very quirky >>>> features you should be aware of: >>>> >>>> 1). Sometimes it helps to define your resultFormat to use "xml" instead of >>>> "e4x". See >>>> http://www.flexer.info/2008/09/10/httpservice-requesting-xml-from-feedburner-gets-parsed-with-xsl-in-ie-browser/ >>>> >>>> 2) Marshalling XML to the Flex/Flash client can be problematic if the HTTP >>>> response headers contain No-Cache. See >>>> http://faindu.wordpress.com/2008/04/18/ie7-ssl-xml-flex-error-2032-stream-error/ >>>> >>>> 3) Apache CXF sometimes returns garbage at the end of the SOAP envelope, >>>> which causes a fault in Flex. See my JIRA entry at >>>> https://issues.apache.org/jira/browse/CXF-1956 . I was able prove, via the >>>> Jira incident's WireShark attachments, that its the Spring/Apache CXF web >>>> service returning the garbage, but it remains unaddressed. I hope they >>>> solve it soon. To solve this, I had to put some "fix-it" logic in the Flex >>>> fault method to strip out the garbage and re-process just the SOAP >>>> envelope. >>>> >>>> Hope something here is helpful. >>>> >>>> Ron Grimes >>>> >>>> >>>> ________________________________ >>>> >>>> From: charlie [mailto:[email protected]] >>>> Sent: Sat 2/21/2009 3:54 AM >>>> To: [email protected] >>>> Subject: CXF 2.1 to CXF 2.2 >>>> >>>> >>>> >>>> Hi all, >>>> >>>> I have upgarded from 2.1.3 -> 2.2-SNAPSHOT as I need the >>>> multipart/form-data >>>> stuff. I have a flex client that runs in different browser calling these >>>> endpoints. Since the upgrade some of the endpoints have stopped working for >>>> the flex client. It was throwing a parseing exception. So i looked at the >>>> XML. From Internet Explorer and Safari I get this: >>>> {"Response":{"expiryDate":1235157506359,"passwordHash":"5f4dcc3b5aa765d61d8327deb882cf99","roleId":3,"securityToken":"<?xml >>>> version=\"1.0\" encoding=\"UTF-8\" ?><TOKEN >>>> TYPE=\"2\"><PUBLIC><MEMBER-ID>0<\/MEMBER-ID> >>>> <NAME>test<\/NAME><HOST>3<\/HOST><EXPIRY-DATE>1235170466370<\/EXPIRY-DATE><\/PUBLIC><CIPHER-TEXT><![CDATA[MNYIeugbGuJ7V1zq9nMm82JTlmiSswJMSokjYI5z9634nPkyJpWgDpuqcg3QkOXZmfCc6BX7m7+togEG4bAFsSggKFgPmlm+nefFLhZ8EOofmSTq\/or0wrMar3WA1WlbZGkGZOjl6A+6v9oSONvsdJW4PLP7Lk06iwwIeZdbFXmeKSWxdonCXw==]]><\/CIPHER-TEXT><\/TOKEN>","status":"OK"}} >>>> >>>> But is correct in Firefox: >>>> <?xml version="1.0" encoding="UTF-8" >>>> standalone="yes"?><Response><expiryDate>1235157552986</expiryDate><passwordHash>5f4dcc3b5aa765d61d8327deb882cf99</passwordHash><roleId>3</roleId><securityToken><?xml >>>> version="1.0" encoding="UTF-8" ?><TOKEN >>>> TYPE="2"><PUBLIC><MEMBER-ID>0</MEMBER-ID> >>>> <NAME>test</NAME><HOST>3</HOST><EXPIRY-DATE>1235170512998</EXPIRY-DATE></PUBLIC><CIPHER-TEXT><![CDATA[MNYIeugbGuJ7V1zq9nMm82JTlmiSswJMSokjYI5z962n6dp9vkO/Kf51/hIjtDzPmfCc6BX7m7+togEG4bAFsSggKFgPmlm+nefFLhZ8EOofmSTq/or0wrMar3WA1WlbZGkGZOjl6A+6v9oSONvsdJW4PLP7Lk06iwwIeZdbFXmeKSWxdonCXw==]]></CIPHER-TEXT></TOKEN></securityToken><status>OK</status></Response> >>>> >>>> It Almost seems like the browser have transform the data. Is there any >>>> thing >>>> I need to do to instruct the marshalling in 2.2? >>>> >>>> Thanks >>>> Charlie >>>> >>>> -- >>>> http://finker.wordpress.com/ >>>> >>>> >>>> >>> >>> >>> >> >
