Return-Path: Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list commons-httpclient-dev@jakarta.apache.org Received: (qmail 18936 invoked from network); 15 Apr 2003 19:30:48 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 15 Apr 2003 19:30:48 -0000 Received: (qmail 25868 invoked by uid 50); 15 Apr 2003 19:32:46 -0000 Date: 15 Apr 2003 19:32:46 -0000 Message-ID: <20030415193246.25867.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: commons-httpclient-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 18996] - Ordering of methods in PostMethod changes behaviour X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . 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=18996 Ordering of methods in PostMethod changes behaviour ------- Additional Comments From ajmas@bigfoot.com 2003-04-15 19:32 ------- In the context of test cases: Another approach to this would be to specify an array of character ranges to test. For example: int[][] tests = new int[][]{{65,120},{19000,21000}}; And then loop through each of the ranges. You even adapt the code so it prints out the array with the java formatting for copying and pasting. Thinking about it, we probably should add several character encoding tests, for several different character sets. With UTF-8 it is important to test characters appearing in various of the alphabets, including those that would appear in the fourth byte - this is the only way to validate that everything is really passing through as expected. Also, we should probably test the case where no character set is specified in the header. In my tests I was getting back cp1215 (or something of the sort, which would be MS-Window's default encoding), rather what the ISO character set that was specified in the docs, when I checked the encoding that was being received by my servlet in Tomcat (4.1.18). This would have to be tested on multiple platforms to ensure that using the tested code with another VM doesn't spring any surprises.