tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 15278] - [PATCH] mod_jk2 for IIS, Bugfix corrupted data ]
Date Wed, 11 Dec 2002 19:03:16 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15278>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15278

[PATCH] mod_jk2 for IIS, Bugfix corrupted data ]





------- Additional Comments From joakim.strom@excosoft.se  2002-12-11 19:03 -------
Response to Costin Manolache:
I agree this is not the most elegant solution, you are right
that incrementing s->content_read is obviously originally intended
to be the responsibility of the caller. But with the current design
that does not work.

There is a loop in readFully(), and if that loop runs
more than once, the caller never gets the chance to update
s->content_read between the calls to s->read(). In some cases
this caused jk2_service_iis_read() to copy some data twice--the
condition for this is if

(long)lpEcb->cbAvailable - s->content_read > 0

So I made sure the value of s->content_read is right even if
several calls are made from readFully(), then reset the value
before exiting that function to make sure it does not get
incremented twice.

In my original post I mentioned that it would perhaps be a good
idea for somebody to make a more neat solution--sorry, that fell
away from the actual bug post. But I have tested on a range of
files sent through the connector, found no problems, and it solved
the original bug.

--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message