DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=38768>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38768 ------- Additional Comments From [EMAIL PROTECTED] 2006-06-08 23:06 ------- Maybe Jonathan can cite a ratified standards which backs up the usage of %uHHHH over and above a de-facto approach. The EMCA specification does not override RFC1738 (and its updates) the encoding scheme may valid inside the EMCA domain but this doesn't make it valid outside in the HTTP domain. My understanding of UCS-2 is that is still relies on a character set being pre-selected (as there are more than 64k entities hence UCS-4). Since there is no character set metadata passed along with the URL it would be an unsafe approach. The last commenter in the following reference quotes extracts from specifications explaining how UTF-8 would work in that situation: http://weblogs.mozillazine.org/gerv/archives/005539.html The spirit of RFC1738 leaves it upto the server implementation on how to interpret a URL especially the meanings of values %80 thru %FF (which would open up the possibility of UTF-8 handling), from the specs point of view a URL is just an identifying token. In testing Jonathans situation Tomcat allows the Servlet to run but sets the parameter value to 'null' as-if it has not been specified. This behaiour is dubious, since there is no reporting mechanism between container and servlet to indicate an uncorrectable error occured during parsing the request. One obvious thing to do would be to send back a HTTP error "400 Bad Request". It concerns me if TC runs the servlet with incorrect parameters. A 'null' or edited value approach might cause the servlet to perform a different action than the request had intended. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
