Chris, Thank you for your answer. You are right about tomcat itself not being involved. I was fooled by the class ByteChunk belonging to tomcat, and didn't see that the MultipartStream belongs in fact to commons-fileupload.jar.
The jbossweb-tomcat55.sar module in jboss 4.0.4.GA does come with commons-fileupload-1.2.jar. I found out that the bug I see was fixed in version 1.2.1 (issue FILEUPLOAD-144 related to issue FILEUPLOAD-135) and verified it solves my problem. Thanks again, Didier DUQUENNOY > Didier, > > On 6/4/14, 11:30 AM, DDU DUQUENNOY Didier wrote: > > I think I found a problem in the way Tomcat parses the POST Http > > Request. It might be related to issues n°40860, 31523 and 42347 > > submitted to bugzilla <https://issues.apache.org/bugzilla>. > > > > I am running on a JBoss 4.0.4 GA server on a windows platform. I > > know it uses a 5.5.x tomcat, but I don't know exactly which > > version. > > Tomcat 5.5.x is no longer supported. We don't support JBoss, here, > either. You'll have to get support from Red Hat at this point, or > upgrade to a version of Tomcat that is supported. > > > Symptoms : When I submit a POST request, sometimes one parameter > > get lost. I can tell using Eclipse's TCP/IP proxy that the value > > was submitted in the request. > > Without knowing what version of 5.5.x you are using, nobody is going > to be able to tell you if a) there is a bug and b) if it was fixed in > a version of Tomcat later than the one you are running. > > I can tell you pretty confidently that Tomcat does not lose request > parameters, even old unsupported versions. ;) > > > Analysis: The POST request looks like that and is 15kB long: << > > -----------------------------7de35e1c190e9e Content-Disposition: > > form-data; name="autoScroll" > > > > 0,0 -----------------------------7de35e1c190e9e > > Content-Disposition: form-data; name="principal:arbre::focused" > > > > false -----------------------------7de35e1c190e9e > > Content-Disposition: form-data; > > name="principal:arbre::expandedNodes" > > It's worth pointing-out that Tomcat did not directly handle multipart > requests until version 7.0.x. If you are having problems with > multipart requests, the problem is likely with either /your/ (of > JBoss's) multipart library or your own code. > > (Oddly, Tomcat does have the package-renamed classes from > commons-http-upload available in the Tomcat 6 source...) > > > Using remote debugging, I found that a MultipartStream object > > analyses the request using a 4KB buffer; this buffer is fed by a > > 8kB buffer used by a ByteChunk object. The pattern > > "-----------------------------7de35e1c190e9e" is called 'boundary'. > > and is repeated for each field. I noted that the hex part of the > > boundary may not be the same length from one POST to another, I > > think that is why the problem does not always occur. > > > > when MultipartStream arrives at the end of its buffer and there is > > not enough bytes left to read the next boundary, it moves the few > > unread bytes to the beginning of the buffer, then loads the next > > chunk of data from the ByteChunk object (see > > MultipartStream$ItemInputStream.makeAvailable()) > > That class does not exist in Tomcat prior to Tomcat 6, and in Tomcat 6 > does not have the "makeAvailable" method. In Tomcat 7, makeAvailable > appears. > > I suspect you are using commons-http-upload, and probably a fairly old > version. > > If this ever was a problem with commons-http-upload, I'm sure it's > been fixed. In any case, you are going to have to upgrade at least > commons-http-upload. I would recommend upgrading just about every > component you currently have, as you are likely to be very out of > date. Security patches, performance improvements, bug fixes, etc. are > all available between your version and the current. > > - -chris Consultez nos sites internet : http://www.sofaxis.com http://www.sofcap-sofcah.com Sofaxis disclaimer : http://www.sofaxis.com/disclaimer-1.html --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
