You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by "Andreas Veithen (JIRA)" <ji...@apache.org> on 2008/12/28 13:03:44 UTC

[jira] Updated: (WSCOMMONS-5) resend does not work (tcpmonitor)

     [ https://issues.apache.org/jira/browse/WSCOMMONS-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andreas Veithen updated WSCOMMONS-5:
------------------------------------

    Component/s:     (was: Utilities)
                 TCPMon

> resend does not work (tcpmonitor)
> ---------------------------------
>
>                 Key: WSCOMMONS-5
>                 URL: https://issues.apache.org/jira/browse/WSCOMMONS-5
>             Project: WS-Commons
>          Issue Type: Bug
>          Components: TCPMon
>         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.
-
You can reply to this email to add a comment to the issue online.