Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 77756 invoked from network); 4 Feb 2002 07:56:29 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 4 Feb 2002 07:56:29 -0000 Received: (qmail 14208 invoked by uid 97); 4 Feb 2002 07:56:33 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 14192 invoked by uid 97); 4 Feb 2002 07:56:32 -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 14181 invoked from network); 4 Feb 2002 07:56:32 -0000 Message-ID: <001901c1ad51$fe46e5e0$1b7d0304@vz.dsl.genuity.net> From: "Bill Barker" To: "Tomcat Developers List" References: Subject: Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt Date: Mon, 4 Feb 2002 00:00:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Archived: msg.XXoer5Ka@sneezy X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ----- Original Message ----- From: To: "Tomcat Developers List" Sent: Sunday, February 03, 2002 10:36 PM Subject: Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt > On Sat, 2 Feb 2002, Bill Barker wrote: > > > > + 4416 URI En/Decoding not working > > > + (investigate and fix if feasible) > > My vote is for LATER, since as I understand the bug it is too late to test > > this well, and the fix (if not done right) has the potential to create > > security problems. The fix is to basically flip UEncoder on it's head, and > > work with "un-safe chars" instead of "safe chars" (as well as to add the > > logic to use the encoding). If Costin (since it's his baby) thinks he's up > > to it, by all means go for it. I just don't want to delay the release for > > the amount of time it would take me to make and be comfortable with the fix > > (esp. since there is a work-around already). > > I'm not sure I understand - the bug seems to be about > DecodeInterceptor using 8859_1 for decoding, even if a different > decoding was found. > > I don't think it is touching UEncoder and the url encoding/decoding. > The url decoding has nothing to do with the charset - we decode > %xx as bytes, the url encoding happens after char->byte and decoding > happen before byte->char conversions ( i.e. uencoding operates on > bytes ). My understanding of this is that if the request is for: /el-ni�o.jsp then most of the time Tomcat will read it correctly. But it will return for requestURI: /el-ni%A1o.jso The "safe chars" map to the same code points under iso-latin-1 and utf-8 (that's why they are "safe chars"). UEncoder is strict in what is safe, but the RFC isn't. You are allowed to use exteded chars if the other side is capable of detecting the charset. > > It is possible we have a bug - and a test case would help finding it. The > code is quite tricky ( I spent huge amounts of time with charset/encoding > issues ), and I agree LATER is good given the risks. But if I have > the test case, I can take a look, it may be a simple fix. > > The way it is supposed to work - first the bytes are url decoded, > then we detect the charset, then convert bytes to chars. > > Am I missing something here ? > > Costin > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > -- To unsubscribe, e-mail: For additional commands, e-mail: