From tomcat-dev-return-36756-apmail-jakarta-tomcat-dev-archive=jakarta.apache.org@jakarta.apache.org Tue Nov 25 00:24:36 2003 Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@www.apache.org Received: (qmail 38887 invoked from network); 25 Nov 2003 00:24:36 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 25 Nov 2003 00:24:35 -0000 Received: (qmail 77067 invoked by uid 500); 25 Nov 2003 00:24:13 -0000 Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 76852 invoked by uid 500); 25 Nov 2003 00:24:12 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 76835 invoked from network); 25 Nov 2003 00:24:12 -0000 Received: from unknown (HELO emerald.servlets.net) (209.162.192.16) by daedalus.apache.org with SMTP; 25 Nov 2003 00:24:12 -0000 Received: from gefionsoftware.com (lsanca1-ar6-4-62-201-147.lsanca1.elnk.dsl.genuity.net [4.62.201.147]) (authenticated bits=0) by emerald.servlets.net (8.12.8/8.12.8) with ESMTP id hAP0OIgx022993 for ; Mon, 24 Nov 2003 16:24:18 -0800 Message-ID: <3FC2AF25.3090003@gefionsoftware.com> Date: Mon, 24 Nov 2003 17:23:49 -0800 From: Hans Bergsten User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-US MIME-Version: 1.0 To: Tomcat Developers List Subject: Re: Justification for URIEncoding addition? References: <8D966D6B75EB7F47AA300241BF2E1D0C01D11688@merc17.na.sas.com> <3FBE8F93.9060700@gefionsoftware.com> <3FC20A63.8030409@apache.org> In-Reply-To: <3FC20A63.8030409@apache.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Remy Maucherat wrote: > Hans Bergsten wrote: > >> Larry Isaacs wrote: >> >>> Hans, >>> >>> The behavior change is unrelated to the use of getParameter() >>> to search for "jsp_precompile". Both Tomcat 3.x and Tomcat 4.x >>> were bit by this log ago and Craig's fix was applied to both. >>> In Tomcat 4's case, it was prior to the 4.0 release. >> >> >> >> Okay, I'm sure you're right that there may be more to it than >> avoiding the getParameter() call in Jasper, but based on what >> I've read, it seems to be part of the problem at least. >> >>> Assuming I have a good grip on the issue, I think it relates >>> to using UTF-8 to decode the path portion of the URL which >>> gets used to determine context, servlet mapping, etc. Then >>> allowing setCharacterEncoding() to change the character encoding >>> for the query portion of the same URL. The Servlet 2.3 and 2.4 >>> specs both say setCharacterEncoding() applies to the request body >>> but don't mention it applying to the query portion of the URL. >> >> >> >> Right, but since the servlet spec doesn't say anything about encoding >> for the query portion, I think we have some room for a sensible >> interpretation. >> >> My concern is that with the new decoding behavior, apps that used to >> work fine suddenly don't, and the reason seems to be that browsers >> in fact ignore the RFC2718 recommendation that TC now enforces. I'm >> all for compliance with all related specs, but in this case it's just >> a recommendation and following it seems to do more harm than good. >> >> I agree it's not as clean as you may want, but are there any real >> problems with decoding the path portion using one charset and the >> query string with another (i.e., the one from getCharacterEncoding()), >> the way it used to be done? > > > I see you as a member of the expert group for the servlet spec. Did you > make out those points during the review period ? If not, then you IMO > have nothing to complain about, esp since Tomcat implements a far more > reasonable and simpler behavior for the URL string handling. Remy, I'm not complaining, I'm just trying to help with ideas for how solve a problem that apparently affects a lot of people. Sigh! Yes, I'm in the servlet spec EG and I did help solving other i18n problems by bringing together all the spec leads for servlets, JSP and JSTL and Sun's i18n guru to fix inconsistencies between these specs. Unfortunately, I missed the query string encoding problem, largely because the way TC handled it before the recent change seemed to work for most apps so I hadn't encountered the problem. My bad. > The specification should have specified something along the lines of: > - The URL must be %xx encoded > - This decodes to bytes reprensenting UTF-8 characters > There's an IETF standard that, I think, states this in B&W. It is being > ignored. Maybe this wouldn't be the case if very popular tech, such as > servlets & JSPs, started mandating it ? This is simply a chiken & egg > issue. And because its a chicken and egg problem, I doubt that it will ever be solved. No server vendor is likely to change the behavior in a way that's incompatible with a large set of browsers. A more sensible way to solve this would be for W3C to change the spec to require the behavior most browsers already implement, even if it's less elegant. > i18n issues with HTTP and srevlets have been known about for years, but > unfortunately they still haven't been addressed properly. > Same with the request dispatcher + wrapping issues that I have pointed > out months ago (and of course, were silently ignored). > > To balance this a little, among the other big issues, I have to give > credit for solving the welcome files in a satisfactory way, as well as > filters with RDs. Filters now make the proprietary APIs provided by the > container irrelevant for most tasks. I'm glad you like something in the new spec ;-) Although, there's more to be done with the welcome file mechanism. I tried to get it all done in 2.4, but we couldn't reach consensus so what there now is still too vague, IMHO. Hans -- Hans Bergsten Gefion Software Author of O'Reilly's "JavaServer Pages", covering JSP 2.0 and JSTL 1.1 Details at --------------------------------------------------------------------- To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org