DO NOT REPLY [Bug 15793] New: - Unable to access form elements
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15793. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15793 Unable to access form elements Summary: Unable to access form elements Product: Tomcat 4 Version: 4.0.4 Beta 1 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am not able to access elements that is used inside FORM of JSP 1 from JSP 2. i.e when a form is submitted from JSP 1 to JSP 2, i could access the elements say INPUT TYPE=TEXT NAME=username created inside the JSP 1 from JSP 2. Is there any solution or fix? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15794] New: - Unable to access form elements from JSP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15794. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15794 Unable to access form elements from JSP Summary: Unable to access form elements from JSP Product: Tomcat 4 Version: 4.0.4 Beta 1 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am not able to access elements that is used inside FORM of JSP 1 from JSP 2. i.e when a form is submitted from JSP 1 to JSP 2, i could not access the elements say INPUT TYPE=TEXT NAME=username created inside the JSP 1 from JSP 2. Is there any solution or fix? -- 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]
DO NOT REPLY [Bug 15795] New: - Request with mailformed URL causes NullPointerException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15795. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15795 Request with mailformed URL causes NullPointerException Summary: Request with mailformed URL causes NullPointerException Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Request with mailformed URL causes NullPointerException. Ex: 213.37.14.93 - - [03/Jan/2003:19:36:05 2000] GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir HTTP/1.0 500 - - - causes 2003-01-03 19:36:05 StandardWrapperValve[default]: Servlet.service() for servlet default threw exception java.lang.NullPointerException at java.io.File.init(File.java:263) at org.apache.naming.resources.FileDirContext.file(FileDirContext.java:880) at org.apache.naming.resources.FileDirContext.getAttributes(FileDirContext.java:487) at org.apache.naming.resources.BaseDirContext.getAttributes(BaseDirContext.java:797) at org.apache.naming.resources.ProxyDirContext.cacheLoad(ProxyDirContext.java:1462) at org.apache.naming.resources.ProxyDirContext.cacheLookup(ProxyDirContext.java:1386) at org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:293) at org.apache.catalina.servlets.DefaultServlet$ResourceInfo.set(DefaultServlet.java:2267) at org.apache.catalina.servlets.DefaultServlet$ResourceInfo.init(DefaultServlet.java:2219) at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:921) at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:506) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2396) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:469) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:405) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:380) at
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
remm2003/01/04 02:00:40
Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
Log:
- Fix case sensitivity bug which prevented keep-alive (and close requests) from
working depending on their case.
Revision ChangesPath
1.54 +1 -1
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Index: Http11Processor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -r1.53 -r1.54
--- Http11Processor.java 19 Dec 2002 14:02:48 - 1.53
+++ Http11Processor.java 4 Jan 2003 10:00:40 - 1.54
@@ -1286,7 +1286,7 @@
// found first char, now look for a match
int myPos = i+1;
for (int srcPos = 1; srcPos srcEnd; ) {
-if (buff[myPos++] != Ascii.toLower(b[srcPos++]))
+if (Ascii.toLower(buff[myPos++]) != b[srcPos++])
break;
if (srcPos == srcEnd) return i - start; // found it
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
remm2003/01/04 02:34:19
Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
Log:
- The check on the first byte should also be case insensitive.
Revision ChangesPath
1.55 +1 -1
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Index: Http11Processor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
retrieving revision 1.54
retrieving revision 1.55
diff -u -r1.54 -r1.55
--- Http11Processor.java 4 Jan 2003 10:00:40 - 1.54
+++ Http11Processor.java 4 Jan 2003 10:34:19 - 1.55
@@ -1282,7 +1282,7 @@
int srcEnd = b.length;
for (int i = start; i = (end - srcEnd); i++) {
- if (buff[i] != first) continue;
+ if (Ascii.toLower(buff[i]) != first) continue;
// found first char, now look for a match
int myPos = i+1;
for (int srcPos = 1; srcPos srcEnd; ) {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http FastHttpDateFormat.java
remm2003/01/04 04:42:33
Modified:util/java/org/apache/tomcat/util/http
FastHttpDateFormat.java
Log:
- Fix caching bug (caused by cut and paste abuse).
Revision ChangesPath
1.3 +1 -1
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/FastHttpDateFormat.java
Index: FastHttpDateFormat.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/FastHttpDateFormat.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- FastHttpDateFormat.java 3 Jan 2003 19:31:00 - 1.2
+++ FastHttpDateFormat.java 4 Jan 2003 12:42:33 - 1.3
@@ -199,7 +199,7 @@
Long cachedDate = null;
try {
-cachedDate = (Long) formatCache.get(value);
+cachedDate = (Long) parseCache.get(value);
} catch (Exception e) {
}
if (cachedDate != null)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets ManagerServlet.java
glenn 2003/01/04 05:43:49
Modified:catalina/src/share/org/apache/catalina/servlets
ManagerServlet.java
Log:
Remove dead code
Revision ChangesPath
1.29 +4 -6
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java
Index: ManagerServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- ManagerServlet.java 18 Sep 2002 14:00:44 - 1.28
+++ ManagerServlet.java 4 Jan 2003 13:43:49 - 1.29
@@ -1103,7 +1103,6 @@
// Identify the appBase of the owning Host of this Context (if any)
String appBase = null;
File appBaseDir = null;
-String appBasePath = null;
if (context.getParent() instanceof Host) {
appBase = ((Host) context.getParent()).getAppBase();
appBaseDir = new File(appBase);
@@ -,7 +1110,6 @@
appBaseDir = new File(System.getProperty(catalina.base),
appBase);
}
-appBasePath = appBaseDir.getCanonicalPath();
}
// Validate the docBase path of this application
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets ManagerServlet.java
glenn 2003/01/04 05:44:37
Modified:catalina/src/share/org/apache/catalina/servlets
ManagerServlet.java
Log:
Remove dead code
Revision ChangesPath
1.5 +4 -6
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java
Index: ManagerServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ManagerServlet.java 8 Dec 2002 13:42:10 - 1.4
+++ ManagerServlet.java 4 Jan 2003 13:44:37 - 1.5
@@ -1103,7 +1103,6 @@
// Identify the appBase of the owning Host of this Context (if any)
String appBase = null;
File appBaseDir = null;
-String appBasePath = null;
if (context.getParent() instanceof Host) {
appBase = ((Host) context.getParent()).getAppBase();
appBaseDir = new File(appBase);
@@ -,7 +1110,6 @@
appBaseDir = new File(System.getProperty(catalina.base),
appBase);
}
-appBasePath = appBaseDir.getCanonicalPath();
}
// Validate the docBase path of this application
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15798] New: - Ampersand in admin password breaks installation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15798. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15798 Ampersand in admin password breaks installation Summary: Ampersand in admin password breaks installation Product: Tomcat 4 Version: 4.1.18 Platform: PC OS/Version: Windows XP Status: NEW Severity: Minor Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I was installing: jakarta-tomcat-4.1.18.exe When the installer asked for admin password, I provided a password that ends with B7. I cannot give you the actual password, but let's say it was something like somethingB7 The installation proceeded normally. After the installation finished, I tried to start Tomcat but it failed. Here are the logs: catalina_log.2003-01-04.txt --- 2003-01-04 16:21:59 UserDatabaseRealm[Standalone]: Exception looking up UserDatabase under key UserDatabase javax.naming.NamingException: The reference to entity B7 must end with the ';' delimiter. at org.apache.naming.NamingContext.lookup(NamingContext.java:844) at org.apache.naming.NamingContext.lookup(NamingContext.java:194) at org.apache.catalina.realm.UserDatabaseRealm.start (UserDatabaseRealm.java:302) at org.apache.catalina.core.ContainerBase.start (ContainerBase.java:1173) at org.apache.catalina.core.StandardEngine.start (StandardEngine.java:347) at org.apache.catalina.core.StandardService.start (StandardService.java:497) at org.apache.catalina.core.StandardServer.start (StandardServer.java:2189) at org.apache.catalina.startup.CatalinaService.start (CatalinaService.java:273) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.BootstrapService.start (BootstrapService.java:245) at org.apache.catalina.startup.BootstrapService.main (BootstrapService.java:307) stderr.log -- Created catalinaLoader in: C:\Program Files\Apache Group\Tomcat 4.1\server\lib 4.1.2003 16:21:56 org.apache.commons.modeler.Registry loadRegistry INFO: Loading registry information 4.1.2003 16:21:56 org.apache.commons.modeler.Registry getRegistry INFO: Creating new Registry instance 4.1.2003 16:21:57 org.apache.commons.modeler.Registry getServer INFO: Creating MBeanServer 4.1.2003 16:21:58 org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on port 8080 4.1.2003 16:21:59 org.apache.commons.digester.Digester fatalError SEVERE: Parse Fatal Error at line 7 column 38: The reference to entity B7 must end with the ';' delimiter. org.xml.sax.SAXParseException: The reference to entity B7 must end with the ';' delimiter. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException (ErrorHandlerWrapper.java:232) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError (ErrorHandlerWrapper.java:213) at org.apache.xerces.impl.XMLErrorReporter.reportError (XMLErrorReporter.java:375) at org.apache.xerces.impl.XMLErrorReporter.reportError (XMLErrorReporter.java:305) at org.apache.xerces.impl.XMLScanner.reportFatalError (XMLScanner.java:1269) at org.apache.xerces.impl.XMLScanner.scanAttributeValue (XMLScanner.java:786) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanAttribute (XMLDocumentFragmentScannerImpl.java:818) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement (XMLDocumentFragmentScannerImpl.java:740) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher .dispatch(XMLDocumentFragmentScannerImpl.java:1477) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument (XMLDocumentFragmentScannerImpl.java:329) at org.apache.xerces.parsers.DTDConfiguration.parse (DTDConfiguration.java:525) at org.apache.xerces.parsers.DTDConfiguration.parse (DTDConfiguration.java:581) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152) at org.apache.xerces.parsers.AbstractSAXParser.parse (AbstractSAXParser.java:1175) at org.apache.commons.digester.Digester.parse(Digester.java:1514) at org.apache.catalina.users.MemoryUserDatabase.open (MemoryUserDatabase.java:416) at
DO NOT REPLY [Bug 10383] - Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10383. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10383 Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely --- Additional Comments From [EMAIL PROTECTED] 2003-01-04 22:28 --- Thank you very much for the patch. Especially the second version of the patch is exactly what I had in mind when I wrote this bug report. One last general request that is not focused on you: When I encounter problems with apache.org software (not only Tomcat) I use bugzilla very often and most of the time I find a hint there that solves my problem. But very often it is hard work to find all the patched files and the revisions of the files containing the patch that resolved the bug in the CVS (partionally CVS is to blame on this problem). Although I know that the CVS is very dynamic, I think it would help a lot if any person who commits a patch to the CVS in reaction to a bug report writes a short note to the bug report which files have been changed by the patch and the revision numbers of these files. Even if these patches change later on, this information is a good base for searching the actual version of the patch to a bug in the CVS. For this bug the note is rather short: Affected files and revisions: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java revisions: 1.10, 1.11 Complete patch: http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java.diff?r1=1.9r2=1.11 Remark: The complete patch line is something I would not see within the scope of this short note in general, but in this case this was so easy that I added it for everyones convenience. Again thanks for the help. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 10383] - Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely
CVSZilla (http://homepages.kcbbs.gen.nz/~tonyg/) supports this kind of functionality quite nicely. Sean Reilly Software Architect, Point2 Technologies, Inc. (306) 955-1855 [EMAIL PROTECTED] -Original Message- (snip) One last general request that is not focused on you: When I encounter problems with apache.org software (not only Tomcat) I use bugzilla very often and most of the time I find a hint there that solves my problem. But very often it is hard work to find all the patched files and the revisions of the files containing the patch that resolved the bug in the CVS (partionally CVS is to blame on this problem). Although I know that the CVS is very dynamic, I think it would help a lot if any person who commits a patch to the CVS in reaction to a bug report writes a short note to the bug report which files have been changed by the patch and the revision numbers of these files. Even if these patches change later on, this information is a good base for searching the actual version of the patch to a bug in the CVS. For this bug the note is rather short: Affected files and revisions: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13 Processor.java revisions: 1.10, 1.11 Complete patch: http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/jav a/org/apache/ajp/tomcat4/Ajp13Processor.java.diff?r1=1.9r2=1.11 Remark: The complete patch line is something I would not see within the scope of this short note in general, but in this case this was so easy that I added it for everyones convenience. Again thanks for the help. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- 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/coreStandardServer.java
Roberto Casanova wrote:
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:
I see the problem with the previous commit - Sorry, I should have
thought about it more before making the quick change. However, the
original problem of second time admin saving url in invalid form still
occurs with revision 1.32. The workaround is to make sure url is in
valid form in datasource page everytime you commit any changes via
admin. Is this workaround feasible?
Amy
Roberto
-Original Message-
From: Amy Roh [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 03, 2003 20:55
To: Tomcat Developers List
Subject: Re: cvs commit:
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core
StandardServer.java
Christoph Seibert wrote:
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.java11 Sep 2002 14:19:33 -1.32
+++ StandardServer.java3 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.)
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(' ').
Thanks,
Amy
Ciao,
Christoph
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
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
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. This is in method
storeNamingResources around line 1822:
@@ -1822,7 +1830,7 @@
writer.print(' ');
}
writer.print(value);
-writer.print(value);
+writer.print(convertStr(value));
writer.println(/value);
for (int j = 0; j indent + 2; j++) {
writer.print(' ');
Actually, I have been running Tomcat with this same fix for a month or
so, and it works well. You can enter special characters (like ) in the
data source url using the admin webapp (no need to escape them), they
get stored in server.xml and read back properly. (I had attached that
patch with the original bug report)
Thanks
Roberto
From: Amy Roh
Sent: Sunday, January 05, 2003 0:46
Roberto Casanova wrote:
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:
I see the problem with the previous commit - Sorry, I should have
thought about it more before making the quick change. However, the
original problem of second time admin saving url in invalid
form still
occurs with revision 1.32. The workaround is to make sure url is in
valid form in datasource page everytime you commit any changes via
admin. Is this workaround feasible?
Amy
Roberto
Christoph Seibert wrote:
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.java11 Sep 2002 14:19:33 -1.32
+++ StandardServer.java3 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.)
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(' ').
Thanks,
Amy
Ciao,
Christoph
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14895] - ServletRequestListener not unregistered when reloading a Webapp Context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14895. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14895 ServletRequestListener not unregistered when reloading a Webapp Context --- Additional Comments From [EMAIL PROTECTED] 2003-01-05 06:00 --- I'm seeing this with a ServletContextListener. If I reload, the config I have in my contextInitialized() is run twice. That doesn't happen if I just do a normal install. Jake -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9526] - HttpServletRequest.getHeader(String) yields inconsistent results depending on how the request header was provided to tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9526. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9526 HttpServletRequest.getHeader(String) yields inconsistent results depending on how the request header was provided to tomcat [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-01-05 07:44 --- A lengthy discussion started on tomcat-dev, and it turns out it was decided it is not a bug. BTW, could you stop whining ? Thanks. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
