Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 75926 invoked from network); 4 Jan 2003 08:37:55 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 4 Jan 2003 08:37:55 -0000 Received: (qmail 4105 invoked by uid 97); 4 Jan 2003 08:39:09 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 4064 invoked by uid 97); 4 Jan 2003 08:39:08 -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 4037 invoked by uid 98); 4 Jan 2003 08:39:07 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Date: Sat, 4 Jan 2003 09:36:27 +0100 Subject: Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardServer.java Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Christoph Seibert To: "Tomcat Developers List" Content-Transfer-Encoding: 7bit In-Reply-To: <000801c2b37a$41cc5f50$0201a8c0@robertoh> Message-Id: <9D62894C-1FBF-11D7-AD3A-0003931820DA@cs.uni-bonn.de> X-Mailer: Apple Mail (2.551) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Am Freitag, 03.01.03 um 23:48 Uhr schrieb Roberto Casanova: > I see another problem with this code. > > Suppose for some reason we have an attribute or resource parameter > value > like the following (without the quotes): > "> corresponds to >" > The correct XML for this string is: > "&gt; corresponds to >" > However this code would write to server.xml: > "> corresponds to >" > The next time the server.xml file is read in, we end up with: > "> corresponds to >" > which is different than the original string. > > In my opinion this portion of the code should be left as it was in > revision 1.32: Actually, after reading the code in context (that is, I've had a look at StandardServer.java), I agree with this. The change to convertStr() results in inconsistent handling of input strings. The question I've been asking myself is: Why should convertStr() treat the input string as if it was a mixture of unescaped and already escaped <,>,&,' and " characters? Since I still don't have the full context, I don't know where the input string comes from, so I can't really answer that. If the input string comes from a form, it should be treated as in revision 1.32, because of what Roberto points out. If it comes from an XML file, no conversion should be necessary, because the XML parser checks for well-formedness of the input file - unless the parser resolves the entity and character references before passing the string, in which case the conversion becomes necessary again. (Wow, I hope this doesn't sound like complete drivel... ;-)) Ciao, Christoph -- --- Christoph Seibert seibert@cs.uni-bonn.de --- -- Farlon Dragon -==(UDIC)==- http://home.pages.de/~seibert/ -- - Who can possibly rule if no one - - who wants to can be allowed to? - D. Adams, HHGTTG - -- To unsubscribe, e-mail: For additional commands, e-mail: