hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 18996] - Ordering of methods in PostMethod changes behaviour
Date Tue, 15 Apr 2003 19:32:46 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=18996>.
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.

Mime
View raw message