RE: BugRat Report #487 - encodeURL() not working in SSL Scheme (Bug in HttpServletResponseFacade.toAbsolut(String url))
Hi, Sorry but bugrat swallowed the workaround: You can install JSSE (Java security Extensions) and set the properties to use the https URLStreamHandler included within there. (Put the JSSE jars in your classpath and add -Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol to your Java commandline.) This solves the problem with the MalformedURLException, but I just noticed that under some circumstances the encodeURL() still doesn't work. Regards, Andreas p.s. Sorry for the typo in the Bug report my e-mail is [EMAIL PROTECTED] feel free to contact me again -Original Message- From: Elsen Christian Sent: Monday, December 11, 2000 9:07 AM To: Stubenrauch,Andreas Subject: WG: BugRat Report #487 - encodeURL() not working in SSL Scheme (Bug in HttpServletResponseFacade.toAbsolut(String url)) -Ursprüngliche Nachricht- Von: BugRat Mail System [mailto:[EMAIL PROTECTED]] Gesendet am: Donnerstag, 7. Dezember 2000 19:33 An: Elsen Christian Betreff: BugRat Report #487 - encodeURL() not working in SSL Scheme (Bug in HttpServletResponseFacade.toAbsolut(String url)) - Sender's Comment - Have you any workaround or patch for this bug?? I'll go after it in a while, and want your input if it's possible.. Thanks Saludos, Ignacio Ortega - End Of Sender's Comment --- Report URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/487 Report #487 Details Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 3.2 Final JVM Release: 1.3 Operating System: Linux/NT OS Release: 2.2.16/4 Platform: i386 Synopsis: encodeURL() not working in SSL Scheme (Bug in HttpServletResponseFacade.toAbsolut(String url)) Description: encodeURL() does not work if the request is sent over https. This is caused in org.apache.tomcat.facade.HttpServletResponseFacade.toAbsolut(S tring url) where an absolute URL is constructed by using new URL(URL, spec) This will throw an MalformedURLException if the URL is https, because no URLStreamHandler exsist for https. (Because of this exception the URL is assumed not to be encodable)
BugRat Report #565 has been filed.
Bug report #565 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/565 REPORT #565 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 3.2 JVM Release: 1.3 Operating System: Linux OS Release: RH6.2 Platform: Linux Synopsis: Security prob: WEB-INF directory is viewable Description: The contents of "hidden" directories like WEB-INF can actually be read by simply placing a double slash "//" before WEB-INF, like so: http://localhost:8080/examples//WEB-INF There may be files inside this or other similar directories which the user does not want to be seen. Title: BugRat Report # 565 BugRat Report # 565 Project: Tomcat Release: 3.2 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Submitter: Ramon Casha ([EMAIL PROTECTED]) Date Submitted: Dec 11 2000, 02:58:12 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: Security prob: WEB-INF directory is viewable Environment: (jvm, os, osrel, platform) 1.3, Linux, RH6.2, Linux Additional Environment Description: When tomcat is used with apache, apache will hide these directories correctly, but if tomcat is directly accessible by giving the port number it opens up this loophole just the same. Report Description: The contents of "hidden" directories like WEB-INF can actually be read by simply placing a double slash "//" before WEB-INF, like so: http://localhost:8080/examples//WEB-INF There may be files inside this or other similar directories which the user does not want to be seen. View this report online...
Re: [PROPOSAL] JSSI for Tomcat
Hans Bergsten typed the following on 19:17 10/12/2000 -0800 But maybe I'm missing something. Are you saying the whole SSI processing should be done as an interceptor instead of as a servlet? Is this something that could be done as a Servlet 2.3 Filter, and so be completely container independent for 2.3 containers? Kief --- bitBull makes the Internet bite: http://www.bitBull.com/demos/
RE: TC 4.0M5 / TC 3.2.1
Which can be a good thing if you're using Linux. But if you're doing development on Windows, it's a PITA to take it to your Linux box, and run it through alien so you can put it on your Windows box. I think RPM must/could be used in Unix world but on Windows environnement you must use something like InstallShield. Apache group allready do that for httpd server and Tomcat need something like this...
Re: Enterprise Tomcat
Falcon cheetah [EMAIL PROTECTED] wrote: I used to work in the second largest financial institute in the world, as they call themselves, here in the US. And they were using stuff other than at that time JServ and early version Tomcat. I believe you're talking about BofA... They're using JRun, it's so nice when I look up at my Account and that thing replies with "500 - Too Many Concurrent Connections" :) Pier -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED]
RE: relative redirect problem using port mapping vip
Thanks, that is what I tought also, but that relative redirect is on the
welcome file code of tomcat so I was just verifying...
Benoit Lalumiere
Software Architect
Jambala Innovation Cell
Ericsson Canada (LMC)
-Original Message-
From: Joe Prevo [SMTP:[EMAIL PROTECTED]]
Sent: Friday, December 08, 2000 4:02 PM
To: [EMAIL PROTECTED]
Subject: Re: relative redirect problem using port mapping vip
Technically you should never be relying on sending a relative redirect to
begin with. The redirect method says that is should be an absolute URL.
Here's the code we use in my project to overcome all of the redirect
issues
we ran into:
protected String getServletUrl(HttpServletRequest req, String
servletInfo)
{
StringBuffer url = new StringBuffer();
String servletPath = req.getServletPath();
int servletSlash = servletPath.lastIndexOf('/');
url.append(req.getScheme());
url.append("://");
url.append(req.getHeader("Host"));
if (servletSlash 0)
url.append('/');
else
url.append(servletPath.substring(0, servletSlash + 1));
url.append(servletInfo);
return url.toString();
}
Hope this helps.
Joe
At 12/7/2000 03:10 PM, you wrote:
Hi all
we use tomcat as a web server on multiple processors having different IP
addresses behind a VIP portal. The VIP maps Ip adreeses and ports also
(therefore a request send to port 80 can reach a processor with port
8080,
etc.).
When doing a relative redirect (response.sendRedirect method), the
Absolute
URL build from the relative URI does not seem to be produced properly.
It
takes the host name from the request header but takes the port from the
web
server (from HttpRequestAdapter.getServerPort). therefore creating a
redirect url command with the right IP address but the wrong port (in our
case 8080 i.o. 80). That seems to be a bug in the tomcat code as it
should
take the port from the request header. But can someone tell me if I
might
be doing something wrong before I change the code...?)
Benoit Lalumiere
Software Architect
Jambala Innovation Cell
Ericsson Canada (LMC)
BugRat Report #566 has been filed.
Bug report #566 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/566 REPORT #566 Details. Project: Jasper Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: non-critical Confidence: public Environment: Release: 4.01 JVM Release: 1.3.0 Operating System: Windows 98 OS Release: 2nd Edition Platform: Win32 Synopsis: Labels in jspc.bat and jasper.bat should not have more than 8 chars Description: (By the way, by changing te label names, I cant get servlet code from any .jsp file. I receive the error: " file .myjsp.jsp generated a general exception java.util.EmptyStackSception". Could you help with this?) Title: BugRat Report # 566 BugRat Report # 566 Project: Jasper Release: 4.01 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: non-critical Confidence: public Submitter: _Anonymous ([EMAIL PROTECTED]) Date Submitted: Dec 11 2000, 09:37:26 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: Labels in jspc.bat and jasper.bat should not have more than 8 chars Environment: (jvm, os, osrel, platform) 1.3.0, Windows 98, 2nd Edition, Win32 Additional Environment Description: Report Description: (By the way, by changing te label names, I cant get servlet code from any .jsp file. I receive the error: " file .myjsp.jsp generated a general exception java.util.EmptyStackSception". Could you help with this?) How To Reproduce: null Workaround: null View this report online...
Re: cvs commit:jakarta-tomcat/src/examples/WEB-INF/classes/examples ShowSource.java
Wouldn't it be a better idea NOT to expand the contents of the WEB-INF
and META-INF directories along with the rest of the webapp and expand
them into some other directory instead?
Instead of making everything available and try to restrict access
afterwards, it would be much safer not to make it available in the first
place...
In fact the same goes for .jsp pages themselves too. The container
recognises incoming request for those pages anyway and will know where
to find the source.
The only things that should be left in the webapps directory is any
static content (or the other way round of course, make a separate
directory with all static content and let that be served by e.g. Apache)
I checked the servlet specification (both 2.2 and 2.3pfd) and I don't
see anything that conflicts with this. If a servlet or .jsp page wants
the static contents of an otherwise dynamic page (such as the source of
a jsp page) it has to use the getResource or getResourceAsStream method
of the ServletContext interface anyway, so the container can return the
correct URL or stream.
I realise this will require some major redesigning, but it would make a
lot of security leaks next to impossible (e.g. misconfiguring apache
wouldn't allow the clients to see any sources even if they inadvertently
have total access to the webapp directory, the problems with
case-sensitivity wouldn't be that security-sensitive any more, etc...).
In a perfect world, Tomcat would scan the web.xml file, determine what
files are actually dynamic content and move these to a separate
directory on the same level as webapps/
However, in a first phase, only the WEB-INF and the META-INF directory
could be moved.
Just firing some ideas...
Luc Vanlerberghe
"Craig R. McClanahan" wrote:
Jon Stevens wrote:
on 12/9/2000 7:07 PM, "[EMAIL PROTECTED]"
[EMAIL PROTECTED] wrote:
+(jspFile.toUpperCase().indexOf("/WEB-INF/") != 0) ||
+(jspFile.toUpperCase().indexOf("/META-INF/") != 0))
Seems like it would be better to define this as a constant somewhere...
public static final String WEB_INF = "/WEB-INF";
I suppose, although there's only one place within the core servlet container
that these directories are significant (in the module that handles static
resources), so a constant would only be used once.
In the case at hand, this is an *application* level component (the ShowSource
custom tag used on the "source.jsp" page, inherited back from JSDK 2.1 days)
that is deliberately ignoring the restrictions of the servlet spec, and you
would not want to make compiling it dependent on the servlet container core
classes anyway ...
Also, I think you should remove the trailing / because the extra character
comparison isn't needed and could cause issues if it isn't there (although
it probably wouldn't be...). :-)
Your suggestion would mean I could not have a directory "WEB-INF-stuff" or
"META-INF-data" in my webapp treated like any other directory. That's going
beyond protecting people and into the realm of infringing their freedom :-).
-jon
--
Honk if you love peace and quiet.
Craig
Re: Problem to limit the number of connections
Dear Arieh, Thank you for your response but I am afraid it does not work! I have entered the following lines in my server.xml file : Connector className="org.apache.tomcat.service.PoolTcpConnector" Parameter name="handler" value="org.apache.tomcat.service.http.HttpConnectionHandler"/ Parameter name="port" value="8008"/ Parameter name="thread_pool" value="on"/ Parameter name="max_threads" value="6"/ Parameter name="max_spare_threads" value="4"/ Parameter name="min_spare_threads" value="2"/ /Connector I have chosen very small values to test it easilly. Unfortunately, I have managed to perform 8 connections to my servlet Do you have further ideas? Thank you! Sophie. Arieh Markel a écrit : Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm list-help: mailto:[EMAIL PROTECTED] list-unsubscribe: mailto:[EMAIL PROTECTED] list-post: mailto:[EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] Delivered-To: moderator for [EMAIL PROTECTED] From: Sophie Lemonnier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Problem to limit the number of connections X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N Hello, I have a machine with little ressouces and with other applications than tomcat are running. Consequently, I would like to prevent too many clients to connect to tomcat... I haven't managed yet to limit the number of connections Can anyone help me? Sophie, you did not mention the version of Tomcat that you are using. In any case, I believe that for 3.2, the solution is in properties for the org.apache.tomcat.service.PoolTcpConnector class: the properties below control the number of threads (which will be associated with inbound socket connections) that the connector has. public static final String THREAD_POOL = "thread_pool"; public static final String MAX_THREADS = "max_threads"; public static final String MAX_SPARE_THREADS = "max_spare_threads"; public static final String MIN_SPARE_THREADS = "min_spare_threads"; What you need to do is modify your server.xml to explicitly set the property values that are appropriate for you: (Here is an example from an old server.xml I was using) Connector className="org.apache.tomcat.service.PoolTcpConnector" Parameter name="handler" value="org.apache.tomcat.service.http.HttpConnectionHandler"/ Parameter name="port" value="8180"/ Parameter name="thread_pool" value="on"/ Parameter name="max_threads" value="100"/ Parameter name="max_spare_threads" value="30"/ Parameter name="min_spare_threads" value="10"/ /Connector Arieh -- Arieh Markel Sun Microsystems Inc. Network Storage500 Eldorado Blvd. MS UBRM11-194 e-mail: [EMAIL PROTECTED] Broomfield, CO 80021 Let's go Panthers Phone: (303) 272-8547 x78547 (e-mail me with subject SEND PUBLIC KEY to get public key)
RE: relative redirect problem using port mapping vip
Hola Benoit: properly. It takes the host name from the request header but takes the port from the web server (from HttpRequestAdapter.getServerPort). therefore creating a redirect url command with the right IP address but the wrong port (in our case 8080 i.o. 80). That seems to be a bug in the tomcat code as it should What version of tomcat are you testing ? I say that because i personally corrected this bug ( was a bug in prior versions of tomcat 3.X before 3.2 Final i think). Saludos , Ignacio J. Ortega
RE: relative redirect problem using port mapping vip
I ma still using 3.1 but I looked at the code of 3.2 and it is doing the same thing... from the redirect in the DefaultServlet class to the toAbsolute method in the HttpServletResponseFacade class and the HttpRequestAdapter.getServerPort() method Can you tell me in which class you put a fix such that I can double check (we are not ready to move to 3.2 yet, that will take at least two months before we migrate...) Benoit Lalumiere Software Architect Jambala Innovation Cell Ericsson Canada (LMC) -Original Message- From: Nacho [SMTP:[EMAIL PROTECTED]] Sent: Monday, December 11, 2000 11:13 AM To: '[EMAIL PROTECTED]' Subject: RE: relative redirect problem using port mapping vip Hola Benoit: properly. It takes the host name from the request header but takes the port from the web server (from HttpRequestAdapter.getServerPort). therefore creating a redirect url command with the right IP address but the wrong port (in our case 8080 i.o. 80). That seems to be a bug in the tomcat code as it should What version of tomcat are you testing ? I say that because i personally corrected this bug ( was a bug in prior versions of tomcat 3.X before 3.2 Final i think). Saludos , Ignacio J. Ortega
RE: relative redirect problem using port mapping vip
I ma still using 3.1 but I looked at the code of 3.2 and it is doing the same thing... from the redirect in the DefaultServlet class to the toAbsolute method in the HttpServletResponseFacade class and the HttpRequestAdapter.getServerPort() method Have a look in the HttpRequestAdapter.getServerPort() method, this was the place where i did the patch, please review it , this solves your concerns ?? Saludos , Ignacio J. Ortega
RE: relative redirect problem using port mapping vip
yes it does solve the problem thanks, I guess I missed that change when I did my diffs. but where is the serverport initialized to -1, in the RequestImpl class, it is still initialized to 0... Benoit Lalumiere Software Architect Jambala Innovation Cell Ericsson Canada (LMC) -Original Message- From: Nacho [SMTP:[EMAIL PROTECTED]] Sent: Monday, December 11, 2000 11:39 AM To: '[EMAIL PROTECTED]' Subject: RE: relative redirect problem using port mapping vip I ma still using 3.1 but I looked at the code of 3.2 and it is doing the same thing... from the redirect in the DefaultServlet class to the toAbsolute method in the HttpServletResponseFacade class and the HttpRequestAdapter.getServerPort() method Have a look in the HttpRequestAdapter.getServerPort() method, this was the place where i did the patch, please review it , this solves your concerns ?? Saludos , Ignacio J. Ortega
Custom error pages!!
Hi ppl: I had posted a very simple query..but had not received any comments. So am i the only unlucky person who's stuck on this simple problem. Any suggestions are welcome plz. I want Custom error pages, in my application, the two solutions i have is to use the "ErrorDocument" directive in Apache or to use the "error-pages" xml element while deploying my servlet in Tomcat (please note that i am using Apache 1.3 and Tomcat 3.2). But somehow both of them are not responding to the changes i try to make. Am only getting some satisfaction if i try and call a page which does not exist through Apache (with netscape...IE...still does nothing). Hoping to get some replies this time. Regards Pankaj
Re: BugRat Report #557 has been filed.
This sounds like an DNS issue. One of the things that the Netscape plugin does is try to resolve the remote host name (jk_nsapi_plugin.c line 405). This forces a DNS lookup which is notorious for having problems on NetWare. There are a couple of ways around it. 1. Make sure that the file sys:\etc\resolv.cfg exists and contains correct information for the domain the server is in. This is where DNS will go to try and resolve addresses to names. 2. If feasable, and the above isn't working, add all the address to name mappings to sys:\etc\hosts. This is the first place that DNS looks to try and resolve an address. 3. Install DNS/DHCP on the server and configure it as your DNS server. I have't done this so I'm not sure of all that is involved here. If you update any of the files, you will need to restart the NetWare server to have it recognize the changes. Hope this helps. Mike AndersonSenior Software EngineerPlatform Services Group[EMAIL PROTECTED]Novell, Inc., the leading provider of Net services softwarewww.novell.com [EMAIL PROTECTED] 12/08/00 04:53PM Bug report #557 has just been filed.You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/557REPORT #557 Details.Project: TomcatCategory: Bug ReportSubCategory: New Bug ReportClass: swbugState: receivedPriority: highSeverity: seriousConfidence: confidentialEnvironment: Release: 3.2 JVM Release: 1.17B Operating System: Netware OS Release: 5.1 SP1 Platform: Intel PentiumSynopsis: Slow performance in redirection for netscapeDescription:Hi.The omcat is fast on netware so is even the webserver from novell.But when using the redirection nsapi_rd.nlm it seems like it is poceesign th request fast and sends it to Tomcat.But to recieve the answer is not working that great.It takes extremly long time, so there must be something in the pass module nsapi_rd.nlm/peter
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java
remm00/12/11 09:07:27
Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java
Log:
- Fix a security problem where /WEB-INF could be accessed using a path like
//WEB-INF. Now, the path is normalized before checking for /WEB-INF.
Revision ChangesPath
1.16 +71 -6
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
Index: DefaultServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- DefaultServlet.java 2000/11/15 01:08:23 1.15
+++ DefaultServlet.java 2000/12/11 17:07:25 1.16
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
1.15 2000/11/15 01:08:23 remm Exp $
- * $Revision: 1.15 $
- * $Date: 2000/11/15 01:08:23 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
1.16 2000/12/11 17:07:25 remm Exp $
+ * $Revision: 1.16 $
+ * $Date: 2000/12/11 17:07:25 $
*
*
*
@@ -112,7 +112,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.15 $ $Date: 2000/11/15 01:08:23 $
+ * @version $Revision: 1.16 $ $Date: 2000/12/11 17:07:25 $
*/
public class DefaultServlet
@@ -719,6 +719,69 @@
}
+/**
+ * Return a context-relative path, beginning with a "/", that represents
+ * the canonical version of the specified path after ".." and "." elements
+ * are resolved out. If the specified path attempts to go outside the
+ * boundaries of the current context (i.e. too many ".." path elements
+ * are present), return codenull/code instead.
+ *
+ * @param path Path to be normalized
+ */
+protected String normalize(String path) {
+
+ // Normalize the slashes and add leading slash if necessary
+ String normalized = path;
+ if (normalized.indexOf('\\') = 0)
+ normalized = normalized.replace('\\', '/');
+ if (!normalized.startsWith("/"))
+ normalized = "/" + normalized;
+
+ // Resolve occurrences of "//" in the normalized path
+ while (true) {
+ int index = normalized.indexOf("//");
+ if (index 0)
+ break;
+ normalized = normalized.substring(0, index) +
+ normalized.substring(index + 1);
+ }
+
+ // Resolve occurrences of "%20" in the normalized path
+ while (true) {
+ int index = normalized.indexOf("%20");
+ if (index 0)
+ break;
+ normalized = normalized.substring(0, index) + " " +
+ normalized.substring(index + 3);
+}
+
+ // Resolve occurrences of "/./" in the normalized path
+ while (true) {
+ int index = normalized.indexOf("/./");
+ if (index 0)
+ break;
+ normalized = normalized.substring(0, index) +
+ normalized.substring(index + 2);
+ }
+
+ // Resolve occurrences of "/../" in the normalized path
+ while (true) {
+ int index = normalized.indexOf("/../");
+ if (index 0)
+ break;
+ if (index == 0)
+ return (null); // Trying to go outside our context
+ int index2 = normalized.lastIndexOf('/', index - 1);
+ normalized = normalized.substring(0, index2) +
+ normalized.substring(index + 3);
+ }
+
+ // Return the normalized path that we have completed
+ return (normalized);
+
+}
+
+
// Private Methods
@@ -1224,8 +1287,10 @@
// Exclude any resource in the /WEB-INF and /META-INF subdirectories
// (the "toUpperCase()" avoids problems on Windows systems)
- if (path.toUpperCase().startsWith("/WEB-INF") ||
- path.toUpperCase().startsWith("/META-INF")) {
+String normalizedPath = normalize(path);
+ if ((normalizedPath == null) ||
+normalizedPath.toUpperCase().startsWith("/WEB-INF") ||
+ normalizedPath.toUpperCase().startsWith("/META-INF")) {
response.sendError(HttpServletResponse.SC_NOT_FOUND, path);
return;
}
cvs commit: jakarta-tomcat/src/doc tomcat-ssl-howto.html
hgomez 00/12/11 09:13:30 Modified:src/doc Tag: tomcat_32 tomcat-ssl-howto.html Log: Updated documentation on SSL (SSLVars) Revision ChangesPath No revision No revision 1.1.2.2 +14 -3 jakarta-tomcat/src/doc/tomcat-ssl-howto.html Index: tomcat-ssl-howto.html === RCS file: /home/cvs/jakarta-tomcat/src/doc/tomcat-ssl-howto.html,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- tomcat-ssl-howto.html 2000/11/29 18:01:56 1.1.2.1 +++ tomcat-ssl-howto.html 2000/12/11 17:13:30 1.1.2.2 @@ -121,6 +121,10 @@ # What is the indicator for the client SSL certificated (default is SSL_CLIENT_CERT) br JkCERTSIndicator SSL_CLIENT_CERT /font/p +pWhen using mod_jk with Apache mod_ssl it is essential to specify "SSLOptions + +StdEnvVars +ExportCertData" in the httpd.conf file.br + Otherwise mod_ssl will not produce the neccessary environment variables for + mod_jk. (Tilo Christ lt;[EMAIL PROTECTED]gt;)/p pWarning, even if mod_jk support both ajp12 (old version from ApacheJServ) and ajp13, only ajp13 could forward SSL informations to tomcat./p hr @@ -163,14 +167,21 @@ and a href="http://www.modssl.org"ModSSL/a (SSL support for Apache)/p h3a name=s61font size="+1"Verify tomcat server.xml configuration file/font/a/h3 blockquote - p font face="Courier New, Courier, mono" size="-1"To use the HTTP with SSL -connector in tomcat, verify that it is activated in server.xml/font/p + p To use the HTTP with SSL connector in tomcat, verify that it is activated +in server.xml/p pfont face="Courier New, Courier, mono" size="-1"lt;Connector className="org.apache.tomcat.service.PoolTcpConnector"gt;br lt;Parameter name="handler" value="org.apache.tomcat.service.http.HttpConnectionHandler"/gt;br lt;Parameter name="port" value="8443"/gt;br lt;Parameter name="socketFactory" value="org.apache.tomcat.net.SSLSocketFactory" -/gt; br +/gt;br +lt;Parameter name="keystore" value="/var/tomcat/conf/keystore" /gt;/fontfont face="Courier New, Courier, mono" size="-1" +br +lt;Parameter name="keypass" value="changeit"/gt;br +lt;Parameter name="clientAuth" value="true"/gt; br lt;/Connectorgt; /font/p + pIn this example we indicate the keystore is file b/var/tomcat/conf/keystore/b. +The keystore password is bchangeit/b and we want client to authentificate./p + blockquotenbsp;/blockquote /blockquote h3a name=s62Generate a SSL certificate (RSA) for tomcat/a/h3 blockquote
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/request SimpleMapper1.java StaticInterceptor.java
craigmcc00/12/11 09:52:31
Modified:src/share/org/apache/tomcat/request Tag: tomcat_32
SimpleMapper1.java StaticInterceptor.java
Log:
Fix a security vulnerability that would display the contents of sensitive
files when a URL like this was used:
http://localhost:8080/examples//WEB-INF/web.xml
This vulnerability appears on Linux (and any other OS that ignores "//" in
the middle of a pathname), but not on Windows.
Submitted by: Ramon Cacha [EMAIL PROTECTED]
PR: BugRat Bug Report #565
Revision ChangesPath
No revision
No revision
1.15.2.4 +2 -2
jakarta-tomcat/src/share/org/apache/tomcat/request/SimpleMapper1.java
Index: SimpleMapper1.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/request/SimpleMapper1.java,v
retrieving revision 1.15.2.3
retrieving revision 1.15.2.4
diff -u -r1.15.2.3 -r1.15.2.4
--- SimpleMapper1.java2000/12/01 03:00:41 1.15.2.3
+++ SimpleMapper1.java2000/12/11 17:52:30 1.15.2.4
@@ -343,8 +343,8 @@
requestURI.substring(contextPath.length()).toUpperCase();
if (relativePath.equals("/META-INF") ||
relativePath.equals("/WEB-INF") ||
-relativePath.startsWith("/META-INF/") ||
-relativePath.startsWith("/WEB-INF/"))
+(relativePath.indexOf("/META-INF/") != 0) ||
+(relativePath.indexOf("/WEB-INF/") != 0))
return 404;
return OK;
1.7.2.5 +3 -1
jakarta-tomcat/src/share/org/apache/tomcat/request/StaticInterceptor.java
Index: StaticInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/request/StaticInterceptor.java,v
retrieving revision 1.7.2.4
retrieving revision 1.7.2.5
diff -u -r1.7.2.4 -r1.7.2.5
--- StaticInterceptor.java2000/11/07 22:52:52 1.7.2.4
+++ StaticInterceptor.java2000/12/11 17:52:30 1.7.2.5
@@ -418,7 +418,9 @@
String relPathU=relPath.toUpperCase();
if ( relPathU.startsWith("WEB-INF") ||
- relPathU.startsWith("META-INF")) {
+ relPathU.startsWith("META-INF") ||
+(relPathU.indexOf("/WEB-INF/") != 0) ||
+(relPathU.indexOf("/META-INF/") != 0) ) {
return null;
}
}
Re: [PROPOSAL] JSSI for Tomcat
Kief Morris wrote: Hans Bergsten typed the following on 19:17 10/12/2000 -0800 But maybe I'm missing something. Are you saying the whole SSI processing should be done as an interceptor instead of as a servlet? Is this something that could be done as a Servlet 2.3 Filter, and so be completely container independent for 2.3 containers? It can (likely) be done as a filter for 2.3 containers, but it still needs help from the container to load and initialize "unnamed" servlets (i.e. for servlet code="className" tags) as far as I can tell. If only named servlets (specified in web.xml) are supported, I believe it can be done completely with the standard API for 2.3, using getNamedDispatcher() to get hold of an RD and then use wrapped request and response objects when it's invoked. 2.2 doesn't allow an RD to use wrapped request/response objects, so this approach doesn't work for 2.2 containers. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
RE: cvs commit:jakarta-tomcat/src/examples/WEB-INF/classes/examples ShowSource.java
(Don't ask me what I think of stupid operating systems that accept "//" in a pathname and simply ignore them like Linux does ... grrr). SGI IRIX 6.5.8 and FreeBSD 4.1-STABLE also behave the same way, I would expect all Unix machines to do the same. -Dave
[VOTE] Compiling JSP's with debugging info
Hi, The only feedback on the more specific proposal was from Costin relating to Tomcat 3.3. I'm not sure if I should interpret this as an overall -1 for committing any of these changes to Tomcat 3.2M1. I have no problem making these changes local to SAS Institute's copy of Tomcat 3.2. To better determine what I should or shouldn't commit to Tomcat 3.2M1, please vote, if you wish, for what you would prefer to be committed. Since later '+' items depend on preceding ones, "+num" will "+1" the items that precede it. +1: (Implement 1,2 3 below) Upgrade Jasper to allow a web.xml servlet init parameter to enable compiling with debug info. Gives Jasper at least the ability to compile with debug information. +2: (Implement 4 5 below) Add a "default JSP options" context attribute which in the absence of a servlet init parameter, could alter the built-in defaults for any boolean JSP options. This would allow a servlet to alter the defaults. +3: (Implement 7, and part of 6 below) Add Context property that sets "default JSP options". This allows the defaults to be set for each individual context in server.xml. +4: (Implement more of 6 below) Add ContextManager property that sets "default JSP options". This allows the defaults for all contexts to be set in server.xml where not overridden by context specific defaults. +5: (Implement the rest of 6 below) Add a System property to supply "default JSP options". This allows the defaults to be set for all contexts outside of server.xml where not overridden by ContextManager or Context. Yes, this is clear overkill, but it helps a little in my situation. :-) -1: (Implement none) Only bug fixes in Tomcat 3.2M1. Cheers, Larry -Original Message- From: Larry Isaacs [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 07, 2000 3:44 PM To: '[EMAIL PROTECTED]' Subject: A better proposal for compiling JSP's with debugging info Hi, To add the ability to compile JSP's with debugging information and achieve more flexible control of Jasper, I propose the following: For Tomcat 3.2M1 1) Add a "debugInfo" property to Options.java and EmbeddedServletOptions.java. The default value is false. 2) Update EmbeddedServletOptions.java to look for a "debuginfo" servlet init parameter to override the default. 3) Update the compiler handling to use the debugInfo property. For more flexible control of Jasper options: 4) Define a JSP default options string which contains letters which associate with the following boolean options in Jasper. d = debugInfo k = keepGenerated l = largeFiles m = mappedFile s = sendErrorToClient If the option letter is preceded by a '+' the option is defaulted true. If preceded by a '-' the option is defaulted false. If not preceded by '+' or '-', it is ignored. 5) Update EmbeddedServletOptions.java to look for a default JSP options string as a context attribute called "jasper.default.options", or maybe "jsp.default.options" (other suggestions?). If the string found, the indicated defaults would be set prior to checking for init parameters, etc. 6) In Tomcat, add a jspDefaultOptions property to Context.java and ContextManager.java. 7) In Tomcat, update DefaultCMSetter.java to look for the jspDefaultOptions property on the context, then ContextManager, then a System property called "tomcat.jsp.default.options" (again, other suggestions?). If found, it sets the context attribute used by Jasper. snip
[PATCH] Initialize SessionIdGenerator PRNG
Attached are patches to StandardManager.java and SessionIdGenerator.java.
These changes cause the PRNG used to generate session ids to be initialized
when a context is initialized instead of when the first session id is
generated. The PRNG used by default in 3.2 (java.security.SecureRandom)
takes a rather long time to return its first random number (about 10-15
seconds on my hardware). I think it makes more sense for the time consuming
initialization stuff to happen when TC starts rather then when requests are
being handled.
Index: StandardManager.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/session/Attic/StandardManager.java,v
retrieving revision 1.11.2.1
diff -u -r1.11.2.1 StandardManager.java
--- StandardManager.java2000/11/18 01:33:59 1.11.2.1
+++ StandardManager.java2000/12/11 20:35:09
@@ -165,6 +165,7 @@
// - Constructor
public StandardManager() {
+SessionIdGenerator.initialize();
}
// - Properties
Index: SessionIdGenerator.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/util/SessionIdGenerator.java,v
retrieving revision 1.3.2.2
diff -u -r1.3.2.2 SessionIdGenerator.java
--- SessionIdGenerator.java 2000/11/18 01:33:59 1.3.2.2
+++ SessionIdGenerator.java 2000/12/11 20:34:06
@@ -114,11 +114,37 @@
*/
public final static long ticDifference = 2000;
-// ** NOTE that this must work together with get_jserv_session_balance()
+/*
+ * Loads the random number generator and gets a random long. This
+ * causes any initialization code for the PRNG to be executed. This
+ * prevents possibly long running code from being executed when the
+ * first session is created.
+ */
+public static void initialize()
+{
+if (randomSource == null) {
+ String className =
+System.getProperty("tomcat.sessionid.randomclass");
+ if (className != null) {
+ try {
+Class randomClass =
+Class.forName(className);
+randomSource =
+(java.util.Random)randomClass.newInstance();
+ }
+ catch (Exception e) {
+e.printStackTrace();
+ }
+ }
+ if (randomSource == null)
+ randomSource = new
+java.security.SecureRandom();
+}
+
+randomSource.nextLong();
+}
+
+// ** NOTE that this must work together with get_jserv_session_balance()
// ** in jserv_balance.c
static synchronized public String getIdentifier (String jsIdent)
{
-StringBuffer sessionId = new StringBuffer();
+ StringBuffer sessionId = new StringBuffer();
if (randomSource == null) {
String className = System.getProperty("tomcat.sessionid.randomclass");
cvs commit: jakarta-tomcat/src/native/mod_jk/iis jk_isapi_plugin.c
nacho 00/12/11 13:17:49
Modified:src/native/mod_jk/iis jk_isapi_plugin.c
Log:
Bug #61 http://znutar.cortexity.com/BugRatAdmin/ShowBug/61
Redirect fails with IE after posting a form to a servlet
Reported Solved by Joe Prevo ( [EMAIL PROTECTED] )
Revision ChangesPath
1.2 +3 -3 jakarta-tomcat/src/native/mod_jk/iis/jk_isapi_plugin.c
Index: jk_isapi_plugin.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/iis/jk_isapi_plugin.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- jk_isapi_plugin.c 2000/08/26 02:03:51 1.1
+++ jk_isapi_plugin.c 2000/12/11 21:17:47 1.2
@@ -56,7 +56,7 @@
/***
* Description: ISAPI plugin for IIS/PWS *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.1 $ *
+ * Version: $Revision: 1.2 $ *
***/
#include httpext.h
@@ -235,7 +235,7 @@
for(i = 0 , len_of_headers = 0 ; i num_of_headers ; i++) {
len_of_headers += strlen(header_names[i]);
len_of_headers += strlen(header_values[i]);
-len_of_headers += 3; /* extra for : and crlf */
+len_of_headers += 4; /* extra for colon, space and crlf */
}
len_of_headers += 3; /* crlf and terminating null char */
@@ -244,7 +244,7 @@
for(i = 0 ; i num_of_headers ; i++) {
strcat(headers_str, header_names[i]);
-strcat(headers_str, ":");
+strcat(headers_str, ": ");
strcat(headers_str, header_values[i]);
strcat(headers_str, crlf);
}
cvs commit: jakarta-tomcat/src/native/iis jk_isapi_plugin.c
nacho 00/12/11 13:18:26
Modified:src/native/iis Tag: tomcat_32 jk_isapi_plugin.c
Log:
Bug #61 http://znutar.cortexity.com/BugRatAdmin/ShowBug/61
Redirect fails with IE after posting a form to a servlet
Reported Solved by Joe Prevo ( [EMAIL PROTECTED] )
Revision ChangesPath
No revision
No revision
1.5.2.1 +3 -3 jakarta-tomcat/src/native/iis/Attic/jk_isapi_plugin.c
Index: jk_isapi_plugin.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/iis/Attic/jk_isapi_plugin.c,v
retrieving revision 1.5
retrieving revision 1.5.2.1
diff -u -r1.5 -r1.5.2.1
--- jk_isapi_plugin.c 2000/06/28 08:03:44 1.5
+++ jk_isapi_plugin.c 2000/12/11 21:18:23 1.5.2.1
@@ -56,7 +56,7 @@
/***
* Description: ISAPI plugin for IIS/PWS *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.5 $ *
+ * Version: $Revision: 1.5.2.1 $ *
***/
#include httpext.h
@@ -235,7 +235,7 @@
for(i = 0 , len_of_headers = 0 ; i num_of_headers ; i++) {
len_of_headers += strlen(header_names[i]);
len_of_headers += strlen(header_values[i]);
-len_of_headers += 3; /* extra for : and crlf */
+len_of_headers += 4; /* extra for colon, space and crlf */
}
len_of_headers += 3; /* crlf and terminating null char */
@@ -244,7 +244,7 @@
for(i = 0 ; i num_of_headers ; i++) {
strcat(headers_str, header_names[i]);
-strcat(headers_str, ":");
+strcat(headers_str, ": ");
strcat(headers_str, header_values[i]);
strcat(headers_str, crlf);
}
CVS Help
I am trying to get CVS working on my machine so I can get download the latest Tomcat codebase but ... the documentation on the website does not say what or how to get a login and password to the CVS server. How do I get these so I can get access to the server? Any help you can provide on getting CVS up and running would be appreciated. Sean
BugRat Report #567 has been filed.
Bug report #567 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/567 REPORT #567 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: non-critical Confidence: public Environment: Release: 3.1+ JVM Release: 1.3 Operating System: Solaris OS Release: 2.7 Platform: SPARC Synopsis: Missing JDBCRealm classes from Tomcat Implementation? Description: Thanks in advance for any of your time spent on this.. (I'm unsure this is actually a bug) The trouble with Apache JDBC setup.. Refer from the *online* doco http://jakarta.apache.org/tomcat/jakarta-tomcat/src/doc/JDBCRealm.howto Specifically the line RequestInterceptor className="org.apache.tomcat.realm.JDBCRealm" debug="99" ...etc throws the following runtime exception for the server FATAL: configuration error java.lang.ClassNotFoundException: org.apache.tomcat.realm.JDBCRealm at org.apache.tomcat.util.xml.ObjectCreate.start(Compiled Code) at org.apache.tomcat.util.xml.XmlMapper.matchStart(Compiled Code) at org.apache.tomcat.util.xml.XmlMapper.startElement(Compiled Code) at com.sun.xml.parser.Parser.maybeElement(Compiled Code) at com.sun.xml.parser.Parser.content(Compiled Code) at com.sun.xml.parser.Parser.maybeElement(Compiled Code) at com.sun.xml.parser.Parser.content(Compiled Code) at com.sun.xml.parser.Parser.maybeElement(Compiled Code) at com.sun.xml.parser.Parser.parseInternal(Compiled Code) at com.sun.xml.parser.Parser.parse(Compiled Code) at org.apache.tomcat.util.xml.XmlMapper.readXml(Compiled Code) at org.apache.tomcat.startup.Tomcat.execute(Compiled Code) at org.apache.tomcat.startup.Tomcat.main(Compiled Code) For future reference to whom does one address Jakarta-Tomcat *queries*? Regards Craig. [EMAIL PROTECTED] Title: BugRat Report # 567 BugRat Report # 567 Project: Tomcat Release: 3.1+ Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: non-critical Confidence: public Submitter: _Anonymous ([EMAIL PROTECTED]) Date Submitted: Dec 11 2000, 06:12:29 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: Missing JDBCRealm classes from Tomcat Implementation? Environment: (jvm, os, osrel, platform) 1.3, Solaris, 2.7, SPARC Additional Environment Description: Report Description: Thanks in advance for any of your time spent on this.. (I'm unsure this is actually a bug) The trouble with Apache JDBC setup.. Refer from the *online* doco http://jakarta.apache.org/tomcat/jakarta-tomcat/src/doc/JDBCRealm.howto Specifically the line View this report online...
Can't stop tomcat on solaris
Hello, I have installed Tomcat 3.1 on Solaris and I have not modified any of the XML files so this is a pretty generic install. After starting tomcat using ./tomcat.sh start I issue the command: ./tomcat.sh stop to stop Tomcat and the process does not stop. It looks as if classes are unloaded and I get a Tomcat Stopped message, but if I look at the processes I still have the Tomcat process running. What can I do to stop Tomcat by using ./tomcat.sh stop ? Thanks, Blair Tingey
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/startup Main.java
costin 00/12/11 16:42:50
Modified:src/facade22/org/apache/tomcat/facade
Servlet22Interceptor.java ServletWrapper.java
WebXmlReader.java
src/facade22/org/apache/tomcat/modules/facade22
JspInterceptor.java
src/share/org/apache/tomcat/context ErrorHandler.java
src/share/org/apache/tomcat/core Context.java Handler.java
src/share/org/apache/tomcat/request AccessInterceptor.java
StaticInterceptor.java
src/share/org/apache/tomcat/startup Main.java
Log:
First round of refactoring for Handler/ServletWrapper. Reorganized the code
to make sure the right order of calls in the right state is enforced.
It seems that Handler is still too complex, and a lot of servlet-specific code
( like handling of init, UnavailableException, etc) need to be moved in
the right place ( ServletWrapper). The problem is that ServletWrapper is too
complex.
I'll start cleaning ServletWrapper and then move init/destroy - Handler will
then be a very simple and maintainable class. I need your review on this one,
please send comments if you find any problem.
Revision ChangesPath
1.6 +4 -1
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/Servlet22Interceptor.java
Index: Servlet22Interceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/Servlet22Interceptor.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- Servlet22Interceptor.java 2000/11/02 21:51:39 1.5
+++ Servlet22Interceptor.java 2000/12/12 00:42:40 1.6
@@ -144,7 +144,10 @@
ServletWrapper sw=new ServletWrapper();
sw.setName( hN );
sw.setContext( ct.getContext() );
- log( "Create handler ");
+ // *.jsp - jsp is a legacy default mapping
+ if( ! "jsp".equals(hN) ) {
+ log( "Create handler " + hN);
+ }
ct.setHandler(sw);
ct.getContext().addServlet( sw );
}
1.14 +124 -143
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/ServletWrapper.java
Index: ServletWrapper.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/ServletWrapper.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- ServletWrapper.java 2000/12/08 23:18:29 1.13
+++ ServletWrapper.java 2000/12/12 00:42:40 1.14
@@ -124,8 +124,19 @@
public String toString() {
if( path==null )
return "Servlet " + name + "(" + servletClassName + ")";
- return "Jsp " + name + "(" + path + ")";
+ return "Jsp " + name + "(" + path + "/" + servletClassName + ")";
}
+
+// Configuration hook
+
+/** This method can called to add the servlet to the web application.
+ * ( typlically used from the config - WebXmlReader ).
+ */
+public void addServlet(Context ctx) throws TomcatException {
+ context=ctx;
+ // System.out.println("Adding servlet " + this );
+ context.addServlet( this );
+}
// Servlet specific properties
public void setLoadOnStartUp( int level ) {
@@ -170,17 +181,21 @@
}
public String getServletClass() {
-return this.servletClassName;
+return getServletClassName();
}
public String getServletClassName() {
-return this.servletClassName;
+ if( servletClassName == null )
+ servletClassName=name;
+return servletClassName;
}
public void setServletClassName(String servletClassName) {
servlet=null; // reset the servlet, if it was set
servletClass=null;
this.servletClassName=servletClassName;
+ if( debug0 path!=null)
+ log( "setServletClassName for jsp " + servletClassName);
}
public void setServletClass(String servletClassName) {
setServletClassName(servletClassName);
@@ -191,7 +206,8 @@
if ( ex != null ) {
if ( ex instanceof UnavailableException
! ((UnavailableException)ex).isPermanent()) {
- // make updated UnavailableException, reporting a minimum of 1 second
+ // make updated UnavailableException, reporting a minimum
+ // of 1 second
int secs=1;
long moreWaitTime=unavailableTime - System.currentTimeMillis();
if( moreWaitTime 0 )
@@ -204,7 +220,7 @@
public void reload() {
- if( initialized ) {
+ if( getState()==STATE_READY ) {
try {
please ignore my previous post
I apologize. This question was supposed to be sent to tomcat-user. -Original Message- From: Cherie Yoon Sent: Monday, December 11, 2000 6:32 PM To: '[EMAIL PROTECTED]' Subject: path Hi, I got apache-tomcat working on linux. now i would like to load jsp page without having to type the parent folder. i.e. (without making change in existing directory structure) localhost/myApp/test.jsp - localhost/test.jsp I made some changes on server.xml and tomcat.conf file (Context path, Alias...etc), but it didn't work. for example, i changed the line in tomcat.conf file Alias /myApp "/usr/local/jakarta-tomcat-3.2/webapps/myApp" to Alias / "/usr/local/jakarta-tomcat-3.2/webapps/myApp" Then i got error. Anybody knows how to do this? thanks in advance, cherie FYI:Error msg: Error:500 Internal Servlet Error java.lang.NullPointerException: at org.apache.tomcat.util.FileUtil.isAbsolute(FileUtil.java:289) at org.apache.tomcat.core.Context.getAbsolutePath(Context.java:257) at org.apache.tomcat.core.Context.getRealPath(Context.java:791) at org.apache.tomcat.facade.ServletContextFacade.getRealPath(ServletContextFa cade.java:136) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:381) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java: 797) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnecti on(Ajp12ConnectionHandler.java:166) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) at java.lang.Thread.run(Thread.java:475)
[SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
Over the last three days, a review of published and soon-to-be-published reports of security vulnerabilities in Tomcat has uncovered a series of problems in the 3.1 final release, and a couple of less serious (but still significant) problems in 3.2. Please vote (quickly) on the following two issues: Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security problems I have just posted a CVS commit that fixes the security vulnerabilities that I know about, plus a release notes document (src/doc/readme) that describes what was changed. I propose to create and announce an official release that reflects these changes. Note that there are no other functionality or bug fixes changes to 3.1 being proposed, nor (IMHO) are any non-security-related fixes likely to be forthcoming in the future. Therefore, I would propose to include a "strong encouragement" for existing 3.1 users to update to 3.2 in order to benefit from the bug fixes and security enhancements that it includes. Proposal #2: Release a Tomcat 3.2.1 that fixes the following security problems plus the patches committed to date. Tomcat 3.2 final has the following security vulnerabilities that have subsequently been fixed in the CVS repository: * A URL like "http://localhost:8080/examples//WEB-INF/web.xml" can expose sensitive information (note the double slash after "examples"). * The "Show Source" custom tag used to display JSP source code can be used to expose sensitive information in WEB-INF. I propose that we cut a Tomcat 3.2.1 release that includes these two fixes, plus other bug fixes that have been committed to date. Additional bug fixes that have been proposed but not yet committed can be included in a subsequent 3.2.2 release. Craig PS: Tomcat 4.0-m4 is vulnerable to the first of the two problems listed above for 3.2 -- a fix has been posted, and will be included in the previously announced milestone 5 release that is imminenet.
Re: PoolTcpEndpoint.java
I only applied a small patch to PoolTcpEndpoint.java. I am directing this to the tomcat-dev list, there are alot of different people who work on the tomcat source, so this type of question is best directed to the list. Glenn Boon Hian Tek wrote: Hi Glenn, I saw that you were the last one who edited the file so I am guessing you are quite knowledgeable on the file. After I downloaded jakarta-tomcat-3.2-src and compile it, somehow when I try to stop the server it always hangs at serverSocket.close() in stopEndpoint(). I have to run "tomcat stop" twice or more before the shutdown will go through. Any ideas? Thanks. Regards, Boon Hian Tek Associate Consultant One World Trade Center (11th Floor) 121 SW Salmon St. Portland, OR 97204 Direct: 503-471-1478 Cell: 317-513-6545 -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security problems +1. Proposal #2: Release a Tomcat 3.2.1 that fixes the following security problems plus the patches committed to date. +1. Remy
Re: CVS Help
On Mon, 11 Dec 2000, Sean wrote: I am trying to get CVS working on my machine so I can get download the latest Tomcat codebase but ... the documentation on the website does not say what or how to get a login and password to the CVS server. How do I get these so I can get access to the server? Any help you can provide on getting CVS up and running would be appreciated. There's pretty decent instructions at http://jakarta.apache.org/site/cvsindex.html It assumes you've got a CVS client installed properly (not a topic for this list; mail me privately if you like). --Jeff Sean
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util SessionIdGenerator.java SessionUtil.java
craigmcc00/12/11 17:01:06
Modified:.Tag: TOMCAT_31_BRANCH build.xml
src/admin/WEB-INF Tag: TOMCAT_31_BRANCH web.xml
src/etc Tag: TOMCAT_31_BRANCH web.xml
src/examples/WEB-INF Tag: TOMCAT_31_BRANCH web.xml
src/examples/WEB-INF/classes/examples Tag: TOMCAT_31_BRANCH
ShowSource.java
src/share/org/apache/jasper/runtime Tag: TOMCAT_31_BRANCH
JspServlet.java
src/share/org/apache/tomcat/service/connector Tag:
TOMCAT_31_BRANCH Ajp12ConnectionHandler.java
src/share/org/apache/tomcat/servlets Tag: TOMCAT_31_BRANCH
DefaultServlet.java
src/share/org/apache/tomcat/util Tag: TOMCAT_31_BRANCH
SessionIdGenerator.java SessionUtil.java
Log:
Fixes for security vulnerabilities in Tomcat 3.1 (final), and proposed
release notes for a Tomcat 3.1.1 maintenance release that *only* fixes the
security related problems.
The identified (and fixed) vulnerabilities are:
- Administrative application enabled by default (removed)
- Case insensitive matches on static files under Windows
- Snoop servlet mappings in example application
- JSP "Show Source" could show WEB-INF files
- Requesting unknown JSP pages showed disk file pathname
- Session ID generation algorithm subject to attack (replaced
with the algorithm from 3.2).
- Tomcat 3.1 could be shut down remotely.
See separate commits for security issues related to 3.2, and discussion of
recommended course of action.
Revision ChangesPath
No revision
No revision
1.44.4.1 +6 -0 jakarta-tomcat/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat/build.xml,v
retrieving revision 1.44
retrieving revision 1.44.4.1
diff -u -r1.44 -r1.44.4.1
--- build.xml 2000/04/05 03:16:15 1.44
+++ build.xml 2000/12/12 01:00:59 1.44.4.1
@@ -91,11 +91,13 @@
classpath="${tomcat.build}/classes"/
!-- admin context --
+!-- Commented out by default because of limited ability to protect usage
mkdir dir="${tomcat.build}/webapps/admin"/
copydir src="src/admin" dest="${tomcat.build}/webapps/admin"/
javac srcdir="src/admin/WEB-INF/classes"
destdir="${tomcat.build}/webapps/admin/WEB-INF/classes"
classpath="${tomcat.build}/classes"/
+--
!-- Test application --
mkdir dir="${tomcat.build}/webapps/test"/
@@ -126,6 +128,7 @@
includes="org/apache/jasper/**"/
!-- Add Tomcat internal javadoc --
+!-- Commented out to avoid incompatibilities with current Ant and Java2
mkdir dir="${tomcat.home}/webapps/ROOT/javadoc" /
javadoc packagenames="org.apache.tomcat.core"
sourcepath="src/share"
@@ -137,6 +140,7 @@
doctitle="Tomcat internal"
bottom="Copyright #169; 2000 Apache Software Foundation. All Rights
Reserved."
/
+--
deltree dir="${tomcat.home}/classes"/
@@ -147,10 +151,12 @@
includes="**" /
deltree dir="${tomcat.home}/webapps/examples"/
+!--
jar jarfile="${tomcat.home}/webapps/admin.war"
basedir="${tomcat.home}/webapps/admin"
includes="**" /
deltree dir="${tomcat.home}/webapps/admin"/
+--
jar jarfile="${tomcat.home}/webapps/ROOT.war"
basedir="${tomcat.home}/webapps/ROOT"
No revision
No revision
1.1.6.1 +15 -0 jakarta-tomcat/src/admin/WEB-INF/web.xml
Index: web.xml
===
RCS file: /home/cvs/jakarta-tomcat/src/admin/WEB-INF/web.xml,v
retrieving revision 1.1
retrieving revision 1.1.6.1
diff -u -r1.1 -r1.1.6.1
--- web.xml 2000/02/18 18:33:03 1.1
+++ web.xml 2000/12/12 01:01:00 1.1.6.1
@@ -5,4 +5,19 @@
"http://java.sun.com/j2ee/dtds/web-app_2.2.dtd"
web-app
+
+security-constraint
+ web-resource-collection
+url-pattern/*/url-pattern
+ /web-resource-collection
+ auth-constraint
+role-nameadmin/role-name
+ /auth-constraint
+/security-constraint
+
+login-config
+ auth-methodBASIC/auth-method
+ realm-nameTomcat Administrative Application/realm-name
+/login-config
+
/web-app
No revision
No revision
1.1.6.1 +12 -0 jakarta-tomcat/src/etc/web.xml
Index: web.xml
===
RCS file: /home/cvs/jakarta-tomcat/src/etc/web.xml,v
retrieving revision 1.1
retrieving revision
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
"Craig R. McClanahan" wrote: [...] Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security problems +0. Is removing TC 3.1 from the download pages an alternative? There shouldn't be any reason for anyone to use TC 3.1 now when 3.2 is released. Upgrading to 3.2.1 could be the recommended action for all TC 3.1 users that need to plug the security holes. Proposal #2: Release a Tomcat 3.2.1 that fixes the following security problems plus the patches committed to date. +1 Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
cvs commit: jakarta-tomcat/src/webpages index.html
craigmcc00/12/11 17:56:02
Modified:src/share/org/apache/tomcat/core Tag: TOMCAT_31_BRANCH
Constants.java
src/share/org/apache/tomcat/session Tag: TOMCAT_31_BRANCH
ServerSessionManager.java
src/webpages Tag: TOMCAT_31_BRANCH index.html
Log:
Update version numbers for the proposed 3.1.1 release, plus a fix that
was mistakenly not included in the previous commit.
Revision ChangesPath
No revision
No revision
1.19.2.1.2.1 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/Constants.java
Index: Constants.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/Constants.java,v
retrieving revision 1.19.2.1
retrieving revision 1.19.2.1.2.1
diff -u -r1.19.2.1 -r1.19.2.1.2.1
--- Constants.java2000/04/14 13:08:10 1.19.2.1
+++ Constants.java2000/12/12 01:56:01 1.19.2.1.2.1
@@ -67,7 +67,7 @@
public class Constants {
public static final String TOMCAT_NAME = "Tomcat Web Server";
-public static final String TOMCAT_VERSION = "3.1";
+public static final String TOMCAT_VERSION = "3.1.1";
public static final String JSP_NAME = "JSP";
public static final String JSP_VERSION = "1.1";
No revision
No revision
1.4.4.1 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/session/ServerSessionManager.java
Index: ServerSessionManager.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/session/ServerSessionManager.java,v
retrieving revision 1.4
retrieving revision 1.4.4.1
diff -u -r1.4 -r1.4.4.1
--- ServerSessionManager.java 2000/03/01 07:51:13 1.4
+++ ServerSessionManager.java 2000/12/12 01:56:02 1.4.4.1
@@ -112,7 +112,7 @@
}
public HttpSession createSession(Context ctx) {
- String sessionId = SessionIdGenerator.generateId();
+ String sessionId = SessionIdGenerator.generateId(null);
ServerSession session = new ServerSession(sessionId);
sessions.put(sessionId, session);
No revision
No revision
1.9.2.1.2.1 +2 -2 jakarta-tomcat/src/webpages/index.html
Index: index.html
===
RCS file: /home/cvs/jakarta-tomcat/src/webpages/index.html,v
retrieving revision 1.9.2.1
retrieving revision 1.9.2.1.2.1
diff -u -r1.9.2.1 -r1.9.2.1.2.1
--- index.html2000/04/14 13:08:10 1.9.2.1
+++ index.html2000/12/12 01:56:02 1.9.2.1.2.1
@@ -4,12 +4,12 @@
meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"
meta name="GENERATOR" content="Mozilla/4.72 [en] (WinNT; U) [Netscape]"
meta name="Author" content="Anil K. Vijendran"
- titleTomcat v3.1/title
+ titleTomcat v3.1.1/title
/head
body
img SRC="tomcat.gif" height=92 width=130 align=LEFTbfont face="Arial,
Helvetica, sans-serif"font size=+3Tomcat/font/font/b
brbfont face="Arial, Helvetica, sans-serif"font size=-1Version
-3.1/font/font/b
+3.1.1/font/font/b
pThis the the default Tomcat home page. This page serves as a quick reference
guide to related resources and is located at:
ul
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
Hans Bergsten wrote: "Craig R. McClanahan" wrote: [...] Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security problems +0. Is removing TC 3.1 from the download pages an alternative? There shouldn't be any reason for anyone to use TC 3.1 now when 3.2 is released. Upgrading to 3.2.1 could be the recommended action for all TC 3.1 users that need to plug the security holes. I'm certainly game to remove 3.1 once we know that 3.1.1 doesn't introduce any nasty problems, but just removing 3.1 doesn't help all the thousands of people who have apps running on 3.1 and who cannot, for various reasons, immediately upgrade. Proposal #2: Release a Tomcat 3.2.1 that fixes the following security problems plus the patches committed to date. +1 Hans Craig
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
on 12/11/2000 5:19 PM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: Over the last three days, a review of published and soon-to-be-published reports of security vulnerabilities in Tomcat has uncovered a series of problems in the 3.1 final release, and a couple of less serious (but still significant) problems in 3.2. Please vote (quickly) on the following two issues: Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security problems I have just posted a CVS commit that fixes the security vulnerabilities that I know about, plus a release notes document (src/doc/readme) that describes what was changed. I propose to create and announce an official release that reflects these changes. Note that there are no other functionality or bug fixes changes to 3.1 being proposed, nor (IMHO) are any non-security-related fixes likely to be forthcoming in the future. Therefore, I would propose to include a "strong encouragement" for existing 3.1 users to update to 3.2 in order to benefit from the bug fixes and security enhancements that it includes. I think that we should just ask people to upgrade to 3.2.x Proposal #2: Release a Tomcat 3.2.1 that fixes the following security problems plus the patches committed to date. Tomcat 3.2 final has the following security vulnerabilities that have subsequently been fixed in the CVS repository: * A URL like "http://localhost:8080/examples//WEB-INF/web.xml" can expose sensitive information (note the double slash after "examples"). * The "Show Source" custom tag used to display JSP source code can be used to expose sensitive information in WEB-INF. +1 I propose that we cut a Tomcat 3.2.1 release that includes these two fixes, plus other bug fixes that have been committed to date. Additional bug fixes that have been proposed but not yet committed can be included in a subsequent 3.2.2 release. +1 PS: Tomcat 4.0-m4 is vulnerable to the first of the two problems listed above for 3.2 -- a fix has been posted, and will be included in the previously announced milestone 5 release that is imminenet. +1 -jon -- Honk if you love peace and quiet.
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
on 12/11/2000 5:59 PM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: I'm certainly game to remove 3.1 once we know that 3.1.1 doesn't introduce any nasty problems, but just removing 3.1 doesn't help all the thousands of people who have apps running on 3.1 and who cannot, for various reasons, immediately upgrade. They can upgrade to 3.1.1 but not 3.2? Huh? No, make people upgrade to 3.2. There are WAY to many advantages to having 3.2. -jon -- Honk if you love peace and quiet.
RE: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security problems +1 Proposal #2: Release a Tomcat 3.2.1 that fixes the following security problems plus the patches committed to date. + 1 Larry
cvs commit: jakarta-tomcat/src/webpages index.html
craigmcc00/12/11 20:51:39
Modified:.Tag: tomcat_32 RELEASE-NOTES
src/share/org/apache/tomcat/core Tag: tomcat_32
Constants.java
src/webpages Tag: tomcat_32 index.html
Log:
Change version numbers (and update the release notes) for a proposed
Tomcat 3.2.1 release.
Revision ChangesPath
No revision
No revision
1.1.2.2 +33 -4 jakarta-tomcat/Attic/RELEASE-NOTES
Index: RELEASE-NOTES
===
RCS file: /home/cvs/jakarta-tomcat/Attic/RELEASE-NOTES,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- RELEASE-NOTES 2000/09/07 11:27:50 1.1.2.1
+++ RELEASE-NOTES 2000/12/12 04:51:37 1.1.2.2
@@ -1,7 +1,7 @@
- Release Notes for:
- ==
- TOMCAT Version 3.2
- ==
+Release Notes for:
+
+ TOMCAT Version 3.2.1
+
0. TABLE OF CONTENTS:
@@ -12,6 +12,7 @@
4. Tomcat: Past, Present, and Future
5. New Features In This Release
6. Known Bugs and Issues
+7. Fixes and Enhancements in Updates
=
@@ -27,7 +28,11 @@
You should read the License Agreement (in the LICENSE file of the top level
directory), which applies to all software included in this release.
+This document adds descriptions of the bug fixes and enhancements that have
+been added in update releases of Tomcat 3.2 since the original release. See
+Section 7 for details.
+
=
2. INSTALLING AND RUNNING TOMCAT
@@ -142,3 +147,27 @@
BAD: /mydirectory/mydocroot
Under Unix, absolute pathnames must begin with a slash ('/') character.
+
+
+=
+7. FIXES AND ENHANCEMENTS IN UPDATES
+
+7.1 Fixes and Enhancements In Release 3.2.1
+
+JDBCRealm - The exception message that is logged when an exception occurs now
+includes a description of the actual SQLException, to aid in debugging the
+cause of the problem. Also, this class is no longer marked "final", so that
+it can be conveniently subclassed by customized versions.
+
+ShowSource - The mechanism used to display the JSP source examples could be
+used to display sensitive files from the WEB-INF and META-INF directories.
+This has been corrected.
+
+SSL Documentation - The "doc/tomcat-ssl-howto.html" document has been updated
+to reflect more current information about using Tomcat+Apache in an SSL
+environment.
+
+Security Vulnerability - Tomcat 3.2 (final) exposes sensitive information when
+a URL like "http://localhost:8080/examples//WEB-INF/web.xml" (note the double
+slash) is presented. This has been corrected so that a 404 is returned.
+
No revision
No revision
1.22.2.8 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/Constants.java
Index: Constants.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/Constants.java,v
retrieving revision 1.22.2.7
retrieving revision 1.22.2.8
diff -u -r1.22.2.7 -r1.22.2.8
--- Constants.java2000/11/29 19:34:26 1.22.2.7
+++ Constants.java2000/12/12 04:51:38 1.22.2.8
@@ -67,7 +67,7 @@
public class Constants {
public static final String TOMCAT_NAME = "Tomcat Web Server";
-public static final String TOMCAT_VERSION = "3.2 (final)";
+public static final String TOMCAT_VERSION = "3.2.1";
public static final String JSP_NAME = "JSP";
public static final String JSP_VERSION = "1.1";
No revision
No revision
1.13.2.8 +2 -2 jakarta-tomcat/src/webpages/index.html
Index: index.html
===
RCS file: /home/cvs/jakarta-tomcat/src/webpages/index.html,v
retrieving revision 1.13.2.7
retrieving revision 1.13.2.8
diff -u -r1.13.2.7 -r1.13.2.8
--- index.html2000/11/29 19:34:29 1.13.2.7
+++ index.html2000/12/12 04:51:38 1.13.2.8
@@ -4,13 +4,13 @@
meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"
meta name="GENERATOR" content="Mozilla/4.72 [en] (WinNT; U) [Netscape]"
meta name="Author" content="Anil K. Vijendran"
-titleTomcat v3.2
Compiling JSP's with debugging info in Tomcat 3.3
BTW, another piece of feedback - would it be possible to implement part of this as an interceptor ? I was assuming for Tomcat 3.3 the JSP option properties would be implemented in JspInterceptor since it is tied to Jasper anyway. Do you have more general plans for JspInterceptor that would suggest these options go in a separate interceptor? For the web.xml changes - you can use a context attribute too. Since JspInterceptor provides a way to specify these options in server.xml, I don't have a real need for a context attribute. I would add a debugInfo property to Jasper's Options.java and with it EmbeddedServletOptions.java. Rather than ignore the debugInfo property, I would add a "debuginfo" init parameter to EmbeddedServletOptions.java just so it can be controlled in web.xml, but I wouldn't anticipate using it. I think server.xml is a more appropriate place for configuring these options. In addition to specifying these JSP options, I'm looking for a way to alter the defaults that get used when these options aren't specified in server.xml. My target is to be able run Tomcat in debugging and non-debugging situations using the same server.xml and without modifying server.xml to switch. Not having to ask the user to modify server.xml helps avoid a potential source of errors and avoids the need to document it for someone who might not be familiar with Tomcat. So far, my best guess is to support a JSP defaults string like that described in the earlier e-mail and obtain this string from a System property, or perhaps a command line argument. My preference would be as a System property. Cheers, Larry
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
On Mon, 11 Dec 2000, Craig R. McClanahan wrote: Tomcat 3.2 final has the following security vulnerabilities that have subsequently been fixed in the CVS repository: * A URL like "http://localhost:8080/examples//WEB-INF/web.xml" can expose sensitive information (note the double slash after "examples"). * The "Show Source" custom tag used to display JSP source code can be used to expose sensitive information in WEB-INF. BTW: I think it should be made clear this is only an issue if you are not using a webserver, like apache, in front of the Container. A properly configured apache renders these vulnerabilites moot. -Nick
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util RequestUtil.java
remm00/12/11 23:50:17
Modified:catalina/src/share/org/apache/catalina/util RequestUtil.java
Log:
- Minor fix : will handle quoted charset names.
Revision ChangesPath
1.10 +8 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/RequestUtil.java
Index: RequestUtil.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/RequestUtil.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- RequestUtil.java 2000/11/15 00:52:45 1.9
+++ RequestUtil.java 2000/12/12 07:50:16 1.10
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/RequestUtil.java,v
1.9 2000/11/15 00:52:45 remm Exp $
- * $Revision: 1.9 $
- * $Date: 2000/11/15 00:52:45 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/RequestUtil.java,v
1.10 2000/12/12 07:50:16 remm Exp $
+ * $Revision: 1.10 $
+ * $Date: 2000/12/12 07:50:16 $
*
*
*
@@ -79,7 +79,7 @@
* General purpose request parsing and encoding utility methods.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.9 $ $Date: 2000/11/15 00:52:45 $
+ * @version $Revision: 1.10 $ $Date: 2000/12/12 07:50:16 $
*/
public final class RequestUtil {
@@ -166,6 +166,10 @@
int end = encoding.indexOf(";");
if (end = 0)
encoding = encoding.substring(0, end);
+encoding = encoding.trim();
+if ((encoding.length() 2) (encoding.startsWith("\""))
+ (encoding.endsWith("\"")))
+encoding = encoding.substring(1, encoding.length() - 1);
return (encoding.trim());
}
