Have you checked the result with a hex editor or anything like that? Is
it possible that txt.getBytes() in the first loop iteration is giving
you some text with a CR in it? It so, your terminal could be overwriting
I am reading a socket directly in a test client. No data of any kind
comes in representing the first chunk flushed. Even if it was
"invisible" it would still need to be preceeded by the "hex
digits\r\n" for the chunk's length. (I originally spotted this
because I was parsing a binary upload and it was missing the first
chunk - the text version is an emailable reproducable illustration.
I can understand that this could be a specified behavior
Like: "to force output into chunked mode, flush a one byte (or more)
record as the first write, it will be discarded, and subsequent
chunks will be written in chuked mode"
But I have found no references to this behavior (or bug report for
it) anywhere.
PK
At 10:42 3/11/2007, you wrote:
Have you checked the result with a hex editor or anything like that? Is
it possible that txt.getBytes() in the first loop iteration is giving
you some text with a CR in it? It so, your terminal could be overwriting
the text with the next line of output, even though it's really there.
Just a shot in the dark.
Try piping wget through od and see what falls out.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
