Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardServer.java
Am Sonntag, 05.01.03 um 02:15 Uhr schrieb Roberto Casanova: You should not revert completely to revision 1.32. There were two changes done to StandardServer.java in your commit of revision 1.33. We discussed only the first change (in method convertStr around line 824) and I think we agree it should be reverted. But the second change done in that same commit actually fixes the original problem (bug 15762) and should be preserved. I agree. I simply forgot to point that out in my last post. In discussing this bug, and looking at bug 15798 (which is Windows-specific, I guess, but nevertheless concerns a similiar issue), I think that the way the XML files are written 'by hand' through PrintWriters is prone to produce bugs of this kind, because it is easy to forget that some strings must be encoded. Isn't there some standard API for _writing_ XML, which takes care of these encoding issues transparently? I thought about maybe having a look at the Cocoon project's Serializers, which I think do something like this via SAX events. Of course, one could also construct a DOM tree and write that out, but I don't know whether this is a good idea in terms of performance. Also, I don't know if encoding issues are taken care of in each approach. Ciao, Christoph -- --- Christoph Seibert [EMAIL PROTECTED] --- -- 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardServer.java
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): gt; corresponds to The correct XML for this string is: amp;gt; corresponds to gt; However this code would write to server.xml: gt; corresponds to gt; 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 [EMAIL PROTECTED] --- -- 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardServer.java
Am Freitag, 03.01.03 um 20:55 Uhr schrieb Amy Roh:
Christoph Seibert wrote:
Fix for bugzilla 15762.
I'm sorry I don't have a better fix right now, but I assume one
would have to iterate through the characters following the ''
until either a ';' is found or a character occurs that is not a legal
part of an entity reference name (or in the case of a character
reference, not one of [0-9] for decimal or [0-9a-fA-F] for
hexadecimal).
I believe iterating through the characters following the '' to look
for ';' is found will fix the problem. A character such as
'#x00020' without following ';' will result in parsing error
where as '#x00020;' will be written as a space(' ').
I'm sorry (really - I'm new here and already I start correcting
other people's code without having contributed any myself), but
I don't think this is sufficient. On encountering a string like
'I like to spell as amp;'
your solution would treat ' as amp;' as a valid entity
reference, and would not escape the first '' character.
However, please also see my answer to Roberto's mail before
making another change.
Ciao,
Christoph
--
--- Christoph Seibert [EMAIL PROTECTED] ---
-- 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: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardServer.java
Hi there,
I think there is a problem with the following fix:
amyroh 2003/01/02 17:59:09
Modified:catalina/src/share/org/apache/catalina/core
StandardServer.java
Log:
Fix for bugzilla 15762.
[...]
diff -u -r1.32 -r1.33
--- StandardServer.java 11 Sep 2002 14:19:33 - 1.32
+++ StandardServer.java 3 Jan 2003 01:59:08 - 1.33
@@ -824,7 +824,15 @@
} else if (c == '') {
filtered.append(quot;);
} else if (c == '') {
-filtered.append(amp;);
+char s1 = input.charAt(i+3);
+char s2 = input.charAt(i+4);
+char s3 = input.charAt(i+5);
+if (((s1 == ';') || (s2 == ';')) || (s3 == ';')) {
+// do not convert if it's already in converted
form
+filtered.append(c);
+} else {
+filtered.append(amp;);
+}
} else {
filtered.append(c);
}
(Note: I haven't had a look at the surrounding code yet, so I have to
assume that 'i' is the position of 'c', that is the '' character.)
This code assumes that character or entity references will not be
shorter than 4 characters (including the delimiters '' and ';')
and no longer than 6. However, the XML specification does not in
any way define restrictions like that. For example, 'd;' is a
valid entity reference (assuming it was defined in the DTD). Worse,
character or entity references can have arbitrary length. For example,
'#x00020' is a valid character reference to the ' ' (space)
character.
I'm sorry I don't have a better fix right now, but I assume one
would have to iterate through the characters following the ''
until either a ';' is found or a character occurs that is not a legal
part of an entity reference name (or in the case of a character
reference, not one of [0-9] for decimal or [0-9a-fA-F] for
hexadecimal).
(Actually, I believe this wheel must already have been invented,
but with only looking at this code snippet, I don't really know.)
Ciao,
Christoph
--
--- Christoph Seibert [EMAIL PROTECTED] ---
-- 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: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
(Tiny) help offer
Hi there, I just subscribed to tomcat-dev in order to discuss a nitpick issue I found in Tomcat 4.1.18. The intro page you get on starting Tomcat for the first time, that is the index page of the ROOT webapp, does not have a correct doctype and is therefore probably invalid HTML, though I must admit I haven't actually checked this yet with a validator. In addition, it uses layout tables, purely presentational elements and more things that (not only) I consider to be bad web design practice. I won't complain longer about this if (a) nobody else thinks this is in the least important, or (b) you let me fix this. ;-) I consider myself to have extensive knowledge in modern, standards-compliant HTML writing, and would like to put this knowledge to use. This way, I hope to get involved in the Tomcat project in a small way. If this goes well, I'd start checking the other example pages as well. What do you think? Ciao, Christoph -- --- Christoph Seibert [EMAIL PROTECTED] --- -- 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
