Aaack - I really REALLY have to oppolgize. One of the people I
manange gave me the dumper client, and I went through it and the
problem is there :|
I'm really really sorry if I caused any flamage and wasted anyone's time.
I respect you people for hammering on me about it. I'll try to audit
Not that anyone cares, but the apparent lost chunk problem was
caused by the header scanner in the dumper client. He created an
InputStreamReader() and it apparently reads exactly two lines ahead
into it's buffer. Since my test case was one line per chunk it
would reliably drop (have in its
Hi!
You have a little error, you are using ++i instead of i++ on:
for(int i = 0; i 5; ++i)
The first iteration is a 1 because the increament is done before instead
of after the looping.
/per jonsson
Peter Kennard skrev:
I have some real mysterious behavior, it seems the first chunk
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Per,
Per Jonsson wrote:
You have a little error, you are using ++i instead of i++ on:
for(int i = 0; i 5; ++i)
The first iteration is a 1 because the increament is done before instead
of after the looping.
I disagree. The loop's update
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter,
Peter Kennard wrote:
I have some real mysterious behavior, it seems the first chunk just doesn't
make it into the output. Doesn't matter how long or short it is.
Seems like a BUG unless I'm doing something wrong.
This code looks fine,
That is not an error, the last item in the (for(;;here)) is executed
after the loop code is executed - the side effect only has effect
within the for statement. (;;(side effect only visible inside
statment in here))
ie: for(;;++i) ad for(;;i++) are equivalent
ie: for(;;val = ++i) ad
On 3/11/07, Peter Kennard [EMAIL PROTECTED] wrote:
or bug report for it
If you file a bug for this, or for the issue you describe in your
other thread, I will immediately resolve them as invalid, obviously.
Rémy
-
To start a
If you file a bug for this, or for the issue you describe in your
other thread, I will immediately resolve them as invalid, obviously.
Curious you mean by this? What is obvious?
Tomcat 5.5 and 6 do make chunked replys to
HTTP1.1 requests that do not explicitly set
content-length if one
No problem :)
I found if you flush before any data is written, it will immediatly
commit the headers, and write a terminal chunk of length 0. Which
is a reasonable behavior.
In the case of a fat upload or page where one doesn't know the exact
length before starting and wants to avoid
On 3/11/07, Peter Kennard [EMAIL PROTECTED] wrote:
Curious you mean by this? What is obvious?
It's quite simple. You've made a number of claims in your two threads,
every time supposedly verified by yourself, and for every one of them,
I can tell you that the opposite is actually true. So
On 3/12/07, Peter Kennard [EMAIL PROTECTED] wrote:
Unless dropping the first data filled chunk is defined as proper and
documented, and supported, behavior, I would consider this a bug.
As I said in my previous post, so far, none of your claims correspond
to the actual behavior of Tomcat. The
to the actual behavior of Tomcat. The 3 examples you have given here
do work as expected.
On what version?
- I have a plain vanilla install of Tomcat 6.0 on a windows XP Pro machine
using the sun jdk (build 1.5.0_11-b03) I am connecting through an
HTTP1.1 connector with the default
- Are the results I get from those 3 examples
expected ?
I actually tried to reproduce your experience.
wget, FireFox etc. - all these HTTP-clients don't have any problems with
tomcat.
What HTTP-client are you using? Is it self-written maybe?
signature.asc
Description: OpenPGP digital
I have some real mysterious behavior, it seems the first chunk just doesn't
make it into the output. Doesn't matter how long or short it is.
Seems like a BUG unles I'm doing something wrong.
/* in my real tiny test servlet */
public void service( ServletRequest req,
14 matches
Mail list logo
