[ http://issues.apache.org/jira/browse/WSCOMMONS-5?page=comments#action_12373226 ]
Sahan Gamage commented on WSCOMMONS-5: -------------------------------------- I have a similar kind of problem. My requirement is to catch a soap 1.2 message. strip the soap stuff and make the message pure xml (remove the soap:env, soap:hdr anf soap:body stuff). So what I do is edit the message (in the message pain in TCPMon) and remove the soap stuff and make the application/soap+xml content type to text/xml. But when I see the content type at the receiving end it is text/plain. So that means the TCPMon has modified my text/xml content type header to text/plain. Also I see something wrong with the content length calculation as well (it does calculate :)) . The length according to its calculation is 144 bytes. But when I calculate it manually it's 147 bytes. Something is missing > resend does not work (tcpmonitor) > --------------------------------- > > Key: WSCOMMONS-5 > URL: http://issues.apache.org/jira/browse/WSCOMMONS-5 > Project: WS-Commons > Type: Bug > Components: Utilities > Environment: WIN2KSP4 JDK1.5.0_06 > Reporter: Franz Fehringer > > I am using tcpmonitor as a valuable tool. > But when i try to resend an already successful sent message i observe that in > the send pane the Content-Length changes to zero and in the receive pane i > get an error message > java.lang.IllegalArgumentException: message is empty > Additionally on the first send nothing appears on the console whrereas on the > resend both outgoing messages show now one with > Content-Length: 586 > and one with > Content-Length: 0 > I face this problem with the current release 1.0 > I sit behind proxy and firewall if that matters and the call is > java -cp C:\Programme\tcpmon-1.0-bin\build\tcpmon-1.0.jar > -Dhttp.proxyHost=proxy -Dhttp.proxyPort=81 > org.apache.ws.commons.tcpmon.TCPMon 80 scftest.pegstour.com 80 > The recalculated Content-Length is the length of the whole send buffer minus > the length of the first line (the one beginning with POST or GET). > In the length calculation for the first line the character(s) of the line > ending is/are included. > The problem now is that the current Java code in Listener.java assumes that > _two_ line separators end the POST/GET line i.e. that there is an empty line > before the real content. > But this is not true, only one is present (at least in my environment, see > above). > Therefore tcpmon seeks to the end of the send buffer instead to the end of > the first line. > For me the following change to tcpmon.java is the cure (diff -b -B > Listener.java Listener.java.orig): > 658c658 > < pos3 = text.indexOf("\r\n"); > --- > > pos3 = text.indexOf("\n\n"); > 660c660 > < pos3 = text.indexOf("\n"); > --- > > pos3 = text.indexOf("\r\n\r\n"); > 662c662 > < pos3 = pos3 + 1; > --- > > pos3 = pos3 + 4; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
