Bug 15278 - [PATCH] mod_jk2 for IIS, Bugfix corrupted data ]
Summary: [PATCH] mod_jk2 for IIS, Bugfix corrupted data ]
Alias: None
Product: Tomcat Connectors
Classification: Unclassified
Component: Common (show other bugs)
Version: unspecified
Hardware: PC All
: P3 critical (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
: 18568 18753 20376 (view as bug list)
Depends on:
Reported: 2002-12-11 16:38 UTC by joakim.strom
Modified: 2008-10-05 03:13 UTC (History)
9 users (show)

Patch from v. 1.27 of jk_requtil.c (958 bytes, patch)
2002-12-11 16:41 UTC, joakim.strom
Details | Diff
jk2 log of problem with debug turned on in WorkerEnv and channel (50.80 KB, text/plain)
2004-03-12 17:38 UTC, G Monroe
Tomcat exception log to match JK2 log (7.38 KB, text/plain)
2004-03-12 17:39 UTC, G Monroe
My compiled version of the isapi_redirector2.dll (220.00 KB, application/octet-stream)
2004-03-12 17:41 UTC, G Monroe

Note You need to log in before you can comment on or make changes to this bug.
Description joakim.strom 2002-12-11 16:38:22 UTC
Bugfix that solves this problem:
Data uploaded from a client occasionally gets corrupted
by the isapi_redirector2 filter, if the length of the
data exceeds approximately 56k bytes.

A word of warning is appropriate here: The fix is in the
common part of jk2 but I have only tested on IIS, where
it does the job.

The fix is from v. 1.27 of jk/native2/common/jk_requtil.c

--- jk/native2/common/jk_requtil.c.orig	2002-12-11 16:52:47.000000000 +0100
+++ jk/native2/common/jk_requtil.c	2002-12-11 17:04:30.000000000 +0100
@@ -434,7 +434,8 @@
                          unsigned  len)
     unsigned rdlen = 0;
-    unsigned padded_len = len;
+    unsigned padded_len = len;
+	long content_read = s->content_read; /* save input value */
     if (s->is_chunked && s->no_more_chunks) {
 	return 0;
@@ -453,8 +454,9 @@
         unsigned this_time = 0;
         if(s->read(env, s, buf + rdlen, len - rdlen, &this_time)) {
             return -1;
-        }
+        }
+		s->content_read += this_time; /* make sure content_read always 
gets incremented */
         if(0 == this_time) {
 	    if (s->is_chunked) {
 		s->no_more_chunks = 1; /* read no more */
@@ -462,7 +464,8 @@
         rdlen += this_time;
-    }
+    }
+	s->content_read = content_read; /* reset */
     return (int)rdlen;
Comment 1 joakim.strom 2002-12-11 16:41:08 UTC
Created attachment 4128 [details]
Patch from v. 1.27 of jk_requtil.c
Comment 2 Costin Manolache 2002-12-11 18:17:17 UTC
It seems the content_read is just mirroring rdlen ( it should have
exactly the same value in all cases ).
So the change is actually: s->content_read = rdlen 

I think it would be better to make this change in the caller of
readFully ( msg_ajp_appendFromServer ).

However the caller has: s->content_read += len.

I have a feeling there is something wrong with the patch.  
Comment 3 joakim.strom 2002-12-11 19:03:15 UTC
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.
Comment 4 Hans-Peter 2003-04-12 19:56:56 UTC
*** Bug 18753 has been marked as a duplicate of this bug. ***
Comment 5 Ignacio J. Ortega 2003-04-12 22:39:45 UTC
*** Bug 18568 has been marked as a duplicate of this bug. ***
Comment 6 Samuel Gabriel 2003-07-01 03:40:52 UTC
*** Bug 20376 has been marked as a duplicate of this bug. ***
Comment 7 Henri Gomez 2004-02-25 15:45:47 UTC
What the current status of this bug ?

It seems there is something wrong between 16bits (IIS ?) and 32bits (Unix).

Pointers welcome
Comment 8 Mladen Turk 2004-02-28 08:23:21 UTC
Fixed in the CVS.
The current implementation is total rewrite of service->read.
It works for me (200K+ post data), so do not reopen this bug unless the
test case is provided.
The only thing I didn't test is when using _very_ slow connections, meaning
that the client is unable to provide 8192 bytes of data withing 60 second
interval. But IMO that's not the problem of this connector.
Comment 9 Sunny Joe 2004-03-07 06:37:38 UTC
Today I checkout the source from cvs. and the version of jk_requtil.c is 1.31, 
but i found that the patch not available. and source code is:

int jk2_requtil_readFully(jk_env_t *env, jk_ws_service_t *s,
                         unsigned char *buf,
                         unsigned  len)
    unsigned rdlen = 0;
    unsigned padded_len = len;

    if (s->is_chunked && s->no_more_chunks) {
	return 0;
    if (s->is_chunked) {
        /* Corner case: buf must be large enough to hold next
         * chunk size (if we're on or near a chunk border).
         * Pad the length to a reasonable value, otherwise the
         * read fails and the remaining chunks are tossed.
        padded_len = (len < CHUNK_BUFFER_PAD) ?
            len : len - CHUNK_BUFFER_PAD;

    while(rdlen < padded_len) {
        unsigned this_time = 0;
        if(s->read(env, s, buf + rdlen, len - rdlen, &this_time)) {
            return -1;

        if(0 == this_time) {
	    if (s->is_chunked) {
		s->no_more_chunks = 1; /* read no more */
        rdlen += this_time;

    return (int)rdlen;

could anybody told me why?

and could anybody teach me how to get the newer isapi_redirector2.dll?
i compile the src code. but it report so many error to me. i've download libary 
APR, apr-util, apr-iconv, pcre.

so could anybody teach me? thak u very much
Comment 10 Sunny Joe 2004-03-08 08:51:22 UTC
this bug is still available in cvs
Comment 11 Mladen Turk 2004-03-08 10:00:21 UTC
Is the bug available or the current CVS HEAD still misbehaves?
As I said, unless you provide the test case, do not reopen the bug.
I have heavily tested the new implementation, and it works for me.
Please provide at least your environment specs like OS, Tomcat, etc...
Comment 12 G Monroe 2004-03-11 21:21:33 UTC
I've been struggling with this as well.  Got this problem setting up redirector 
in IIS using current release.  Saw that it was supposed to be fixed in CVS so I 
built a new .dll from full export of current CVS Head (as of 9 Mar 2004) using 
current MS Platform SDK and VS 6.0 SP5 with srclib from httpd-2.0.48.

Installed this on a Win2k3 Server with IIS 5.0 with latest MS patches.

Connected it to a Tomcat 4.1.29 server running as a service on same box.

Created an examples-test.war from Tomcat examples.

Went to Tomcat Web Application Manager, ie. http:/<server>/manager/html.  
(NOTE:  Make sure the IIS virtual directory that points to your DLL only has 
Anonymous security checked in it's directory properties... otherwise, you can't 
authenticate with TC) 

Used the examples-test.war in the "Upload a WAR file to install" section of the 

Received the error:  

FAIL - Install Upload Failed, Exception: Processing of multipart/form-data 
request failed. Stream ended unexpectedly

Repeated process going directly to Tomcat's HTTP connector, works fine.

Duplicated the problem with an NT 4.0/IIS 4.0 pointing to Tomcat 4.1.29 install 
on an XP Pro box (running as service).
Comment 13 Mladen Turk 2004-03-12 09:08:00 UTC
Testest on 5.0.19/WIN XP Pro:
Deploy -> Select WAR file to upload:
Browse -> selected struct-documentation.war (4094103 bytes)
Couple of seconds, and it passes smoothly. The war is uploaded and deployed.
And it works all the time, for any file sizes from 4k to mutimegabyte ones.

So can you check that with TC5?
Also can you give some detailed jk2.log, Setting Alternate file logger and 
level to debug for workerEnv and channel.socket.

Also you might consider attaching your isapi_redirector2.dll that you've built.
Comment 14 G Monroe 2004-03-12 17:38:47 UTC
Created attachment 10766 [details]
jk2 log of problem with debug turned on in WorkerEnv and channel
Comment 15 G Monroe 2004-03-12 17:39:42 UTC
Created attachment 10767 [details]
Tomcat exception log to match JK2 log
Comment 16 G Monroe 2004-03-12 17:41:08 UTC
Created attachment 10768 [details]
My compiled version of the isapi_redirector2.dll
Comment 17 G Monroe 2004-03-12 17:45:44 UTC
Need to find a machine to set up Tomcat 5.0 for testing.. ACC Tourney may delay 

In case it's needed for use with the JK2 debug attachment:  The war file I was 
testing with was 174,597 bytes.

FWIW, The isapi_redirector2.dll was compiled under WinXP Pro.
Comment 18 Mladen Turk 2004-03-12 19:57:51 UTC
Well, I've tried your dll and it works on my side with TC5.
I'll try to test this with 4.1.30 to see if this works.
Comment 19 Mladen Turk 2004-03-12 20:14:17 UTC
Apache Tomcat/4.1.30-LE-jdk14 JVM 1.4.2_03-b02 Windows XP 5.1 x86
It works even with your dll.
There are very strange lines in your jk2.log
They shuld mosly be:
... jk_ws_service_t::read buffer readed 8186 ...
You are getting much random read values from 162 bytes to 8K.
Do you have slow line?
Comment 20 Sunny Joe 2004-03-15 06:31:06 UTC
tomcat-5.0.19/Windows 2000 SP4/j2sdk1.4.2_03/G Monroe's DLL/IIS 5.0
still have this bug.
and I use LAN to upload file. so my line not a slow line.
Comment 21 Mladen Turk 2004-03-15 08:34:17 UTC
Hi, can you guys test with the provided current isapi_redirector2.dll
Can be downloaded from:

It includes the most recent bug fix, but have no idea why that worked on my 
Comment 22 G Monroe 2004-03-15 19:02:01 UTC
Tried Mladen's DLL with mixed success.  I installed his redirector and the 
included MSVCRT71.dll on an NT Server IIS installation and a Win2k Server IIS 
installation. All of them running on a switched 100Mb network.  Upload requests 
to these came from an external PC. 

The NT setup pointed to an external Win2k machine that could run either Tomcat 
4.1.29 or 5.1.19.  

The Win2k setup was connected to Tomcat 4.1.29 running on the same machine. 
(Some other work going on this machine prevented me from point it to a 5.0 

The Win2k set up worked once I updated the System32 directory to have the 

The NT set up failed at all times.

So, the questions are:

1) What's different about your compile process/code base? ('Cause I know the 
security guys are going to ask where the code came from/can we compile it...)

2) Where did that version of MSVCRT come from? (same security issue..).

3) Does the NT failure really matter? (we've got some legacy stuff we're 
running that's being phased out which is why I need to test on it.)
Comment 23 Henri Gomez 2004-03-16 09:06:56 UTC
Thanks to use tomcat-dev for this kind of dev settings
Comment 24 Abraham Lloyd 2004-03-22 19:49:33 UTC
I was unable to get this working on Two Win2k machines fully patched.  If this 
makes a difference, my original jk2 connector install was done using 

I tested the file found at http://www.apache.org/~mturk/isapi_redirector2.zip
 and repeatedly was able to generate the upload failure messages with files 
over 50k in size via IIS.  

Comment 25 Abraham Lloyd 2004-03-22 19:52:22 UTC
Sorry -- one last comment:  My tests were done using:

- Win2k
- IIS v5
- j2sdk1.4.203
- Tomcat v5018 and v5019

Comment 26 Mladen Turk 2004-03-22 20:23:27 UTC
It works perfectly on my side.
Event tried the pervesions like uploading from vmware vitual machine.
So, I suggest that you wait until we release 2.0.4.
With official binaries, we'll have some comon test ground.
Comment 27 Samuel Gabriel 2004-04-02 23:26:35 UTC
Just wanted to add to this bug that it is still there and there is no doubt. 
The problem is it doesn't happen all the time. I had two different clients 
using Windows XP and IE 6 latest service packs and patches installed on both. 
When I try to upload files from my machine which has the same configuration it 
works for me. 
I had JK 1 as well as JK2 installed on the server so after I start getting 
these error messages I went to IIS and revert back to use the old DLL, I know 
that this steps work because i have tried it before. Then went back to these 
machines that were always having troubles and guess what it worked. The 
version that I tested was the same version that was published in this bug. 
Comment 28 Samuel Gabriel 2004-04-02 23:31:19 UTC
Just wanted to add, that the test on the previous post was done on both IIS 
5.0 on a W2K Sp4 and IIS 6.0 on a W2K3 server. The test failed on both cases 
when using JK2.
Comment 29 Mladen Turk 2004-04-03 05:59:07 UTC
You've convince me.
If I build a fixed binary will you be willing to test?
Since I cannot reproduce the bug the testing will be on your side of the wire.
Also the future correspondance should go trough standard TC dev list.
Please subscribe if not.
Comment 30 Samuel Gabriel 2004-04-03 06:28:14 UTC
Yes i will be willing to help with the test. I can install the version on the 
dev server which is IIS 5.0 with TC 5.0 and W2K and use these same machines to 
do the test.

As of the email issue, I am subscribed but i get way too many emails i can't 
read them all. the bug report is very good because I am cc ed and i get the 
email in my inbox rather than the TC folder.
Comment 31 Mladen Turk 2004-04-05 12:55:58 UTC
There is a binary build at:
or you can build from CVS.

It includes the latest fixes that IMO should resolve the issue.
Waiting for the test results :)

In case that the bug is still present;
The best would be that you put following in your config to enable DEBUG and 
file logging.
I'm interested in the jk_ws_service_t::read lines.

info=Native logger


info=Global server options


info=Manager Application.
Comment 32 Geoff Oakham 2004-04-06 17:20:52 UTC
Hi Mladen,

That build seems to work for me; thanks for posting it!
The systems I tested it with were:

-w2k machines
-IIS v5.xxx
-Tomcat 4.1.29
-J2sdk 1.4.2_03 (and 1.4.2_01, I believe)


Comment 33 Karl von Randow 2004-05-18 04:44:14 UTC
Successful test:

Windows 2000 Server
Tomcat 4.1.29
JDK 1.4.1_02
Isapi redirector from: http://jakarta.apache.org/~mturk/isapi_redirector2.zip

The current 2.0.4 release of isapi_redirector2 did NOT work.
Comment 34 Adam Rabung 2004-06-02 21:31:56 UTC
Successful test:

Windows 2000 Server
Tomcat 5.0.25
JDK 1.4.2_04
Isapi redirector from: http://jakarta.apache.org/~mturk/isapi_redirector2.zip

The current release of isapi_redirector2 distributed with tomcat 5.0 did NOT work.
Comment 35 Samuel Gabriel 2004-06-03 14:38:18 UTC
I have tested the version posted 
and it works fine, tried it from the machines that was working before and it 
works now.
Win 2000 SP4 
JDK 1.4.2_03
Comment 36 Andy Armstrong 2004-07-05 13:51:25 UTC
Does anyone know whether this bug really is fixed? I've got a client who's
having a problem with the IIS redirector that sounds exactly like this bug. I
had him try the redirector attached above and the problem persists.

No problem with Tomcat directly on 8080 so it seems likely that it's happening
somewhere inside the redirector.
Comment 37 Alexander Kediarov 2004-07-29 12:32:19 UTC
I have this bug on the following server:
Windows Server 2003
IIS 6.0
Tomcat 4.1.30

I installed the latest version of isapi_redirector2.dll (225,280 bytes). It 
works fine but I could not upload files bigger than 50k. I'm trying to upload 
files via dial-up connection (56 Kbit/sec) and via fast channel (up to 1 
Mbit/sec). At the same time I can upload any files when I do it locally on the 
You may use link to reproduce the problem.

Let me know what kind of debug info you need to fix the bug. Thank you.
Comment 38 Mark Thomas 2004-07-29 19:33:08 UTC
This has been fixed in CVS as is clear from the comments above. There has not, 
as yet, been a formal JK2 release that includes this fix.

The successful tests were performed with a build from CVS 

Sites using the last release 2.0.4 will still experience this bug.

Please do not re-open this bug report.
Comment 39 Terje 2004-11-18 11:17:35 UTC
More info on the problem. I see in the postings that some are not able to 
reproduce the error. We have a situation where people that have a high speed on 
their network is able to upload files just fine. People on slower lines can 
upload most of the time and people on slow lines cannot upload at all.

I applied the Isapi redirector from: 

Now all users can upload no matter what connection they have.
I was happy with the patch until I started getting reports like this:

2004-11-18 10:59:51 StandardWrapperValve[jsp]: Servlet.service() for servlet 
jsp threw exception
java.io.IOException: Stream closed
	at org.apache.jasper.runtime.BodyContentImpl.ensureOpen
	at org.apache.jasper.runtime.BodyContentImpl.write
	at org.apache.jasper.runtime.BodyContentImpl.write
	at org.apache.jsp.indexuf_jsp._jspService(indexuf_jsp.java:1775)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
	at org.apache.jasper.servlet.JspServletWrapper.service
	at org.apache.jasper.servlet.JspServlet.serviceJspFile
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
	at org.apache.catalina.core.ApplicationFilterChain.doFilter
	at org.apache.catalina.core.StandardWrapperValve.invoke
	at org.apache.catalina.core.StandardValveContext.invokeNext
	at org.apache.catalina.core.StandardPipeline.invoke
	at org.apache.catalina.core.StandardContextValve.invokeInternal
	at org.apache.catalina.core.StandardContextValve.invoke
	at org.apache.catalina.core.StandardValveContext.invokeNext
	at org.apache.catalina.core.StandardPipeline.invoke
	at org.apache.catalina.core.StandardHostValve.invoke
	at org.apache.catalina.core.StandardValveContext.invokeNext
	at org.apache.catalina.valves.ErrorReportValve.invoke
	at org.apache.catalina.core.StandardValveContext.invokeNext
	at org.apache.catalina.core.StandardPipeline.invoke
	at org.apache.catalina.core.StandardEngineValve.invoke
	at org.apache.catalina.core.StandardValveContext.invokeNext
	at org.apache.catalina.core.StandardPipeline.invoke
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
	at org.apache.coyote.tomcat5.CoyoteAdapter.service
	at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:296)
	at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:372)
	at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:694)
	at org.apache.jk.common.ChannelSocket.processConnection
	at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:807)
	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
	at java.lang.Thread.run(Thread.java:595)

I started getting these errors when the load on the server grew in the morning 
after I applied the patch.

I have the following config:
IIS 6 (win2003)
Tomcat 5.0.25
java SDK 1.5 RC
Isapi redirector from: http://jakarta.apache.org/~mturk/isapi_redirector2.zip

Comment 40 Mark Thomas 2004-11-18 23:53:34 UTC
As your comments state, this bug is fixed. If you have identified another 
issue, please open a new bug report.
Comment 41 Terje 2004-11-21 12:36:51 UTC
(In reply to comment #40)
> As your comments state, this bug is fixed. If you have identified another 
> issue, please open a new bug report.
OK. I did not create another bug because the way this bug is fixed has created 
another bug. 
Comment 42 ARobert 2006-06-09 08:57:33 UTC
Hello, i'm trying to fix this bug too... 

I still have the exception : 
org.apache.commons.fileupload.FileUploadException: Processing of
multipart/form-data request failed. Stream ended unexpectedly

Can you explain what we have to do to fix the bug. I just replaced the
isapi_redirector2.dll in the tomcat\bin folder. Was that the correct method? 

Please help 
Comment 43 ARobert 2006-06-09 08:57:51 UTC
Hello, i'm trying to fix this bug too... 

I still have the exception : 
org.apache.commons.fileupload.FileUploadException: Processing of
multipart/form-data request failed. Stream ended unexpectedly

Can you explain what we have to do to fix the bug. I just replaced the
isapi_redirector2.dll in the tomcat\bin folder. Was that the correct method? 

Please help 
Comment 44 Mark Thomas 2006-06-09 11:30:32 UTC
JK2 is no longer supported.

Please see http://tomcat.apache.org/tomcat-4.1-doc/config/connectors.html for an
up to date list of supported connectors
Comment 45 ARobert 2006-06-09 12:19:51 UTC
You're right, my company still use it, and has to use it.

Is it still possible de patch it ? Or not ? I know the problem is quite old
(2004) maybe someone remembers how to do ? 

If you could help it's would be great
Comment 46 Mladen Turk 2006-06-09 20:55:05 UTC
The fact that you or your company used mod_jk2 does not
mean that it will be moved from deprecated status.
You have the source code, so feel free to maintain it by

Please do not reopen this case.