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 @@ break; } rdlen += this_time; - } + } + s->content_read = content_read; /* reset */ return (int)rdlen; }
Created attachment 4128 [details] Patch from v. 1.27 of jk_requtil.c
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.
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.
*** Bug 18753 has been marked as a duplicate of this bug. ***
*** Bug 18568 has been marked as a duplicate of this bug. ***
*** Bug 20376 has been marked as a duplicate of this bug. ***
What the current status of this bug ? It seems there is something wrong between 16bits (IIS ?) and 32bits (Unix). Pointers welcome
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.
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 */ } break; } 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
this bug is still available in cvs
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...
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 manager. 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).
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.
Created attachment 10766 [details] jk2 log of problem with debug turned on in WorkerEnv and channel
Created attachment 10767 [details] Tomcat exception log to match JK2 log
Created attachment 10768 [details] My compiled version of the isapi_redirector2.dll
Need to find a machine to set up Tomcat 5.0 for testing.. ACC Tourney may delay this..lol 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.
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.
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?
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.
Hi, can you guys test with the provided current isapi_redirector2.dll Can be downloaded from: http://www.apache.org/~mturk/isapi_redirector2.zip It includes the most recent bug fix, but have no idea why that worked on my site.
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 setup). The Win2k set up worked once I updated the System32 directory to have the msvcrt71.dll. 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.)
Thanks to use tomcat-dev for this kind of dev settings
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 http://www.shiftomat.com/opensource/. 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.
Sorry -- one last comment: My tests were done using: - Win2k - IIS v5 - j2sdk1.4.203 - Tomcat v5018 and v5019
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.
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.
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.
Ok, 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.
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.
There is a binary build at: http://jakarta.apache.org/~mturk/isapi_redirector2.zip 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. [logger] info=Native logger level=DEBUG [logger.file:0] level=DEBUG file=${serverRoot}/logs/jk2.log .... [workerEnv:] info=Global server options timing=1 debug=0 logger=logger.file:0 ... [uri:/manager/*] info=Manager Application. context=/manager debug=10
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) Cheers, Geoff
Successful test: IIS 5 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.
Successful test: IIS 5 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.
I have tested the version posted http://jakarta.apache.org/~mturk/isapi_redirector2.zip and it works fine, tried it from the machines that was working before and it works now. Configuration Win 2000 SP4 IIS JDK 1.4.2_03
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.
I have this bug on the following server: Windows Server 2003 IIS 6.0 Tomcat 4.1.30 JDK 1.4.2.05 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 server. You may use link http://216.122.144.202/test.jsp to reproduce the problem. Let me know what kind of debug info you need to fix the bug. Thank you.
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 (http://jakarta.apache.org/~mturk/isapi_redirector2.zip) Sites using the last release 2.0.4 will still experience this bug. Please do not re-open this bug report.
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: http://jakarta.apache.org/~mturk/isapi_redirector2.zip 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 (BodyContentImpl.java:576) at org.apache.jasper.runtime.BodyContentImpl.write (BodyContentImpl.java:140) at org.apache.jasper.runtime.BodyContentImpl.write (BodyContentImpl.java:157) 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 (JspServletWrapper.java:298) at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:292) 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 (ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal (StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:117) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext (StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service (CoyoteAdapter.java:160) 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 (ChannelSocket.java:626) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:807) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:644) 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
As your comments state, this bug is fixed. If you have identified another issue, please open a new bug report.
(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.
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
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
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
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 yourself. Please do not reopen this case.