Re: keeping sessions when switching from http to https
Be careful when you experiment and report on this. I have found that IE 5 carries cookies from http to https but Netscape 4 does not. I have only tested this with cookies, not URL-rewriting. I'm grumped by this problem, but it's not critcal for me yet --- for my current site, I think I can get away with only having sessions on the https side. Mike
Does Tomcat 3.2.2 respect the If-Modified-Since HTTP header?
I'm using Tomcat 3.2.2 on vanilla AIX 4.3.3 and IBM's jdk 1.3. I suspect the If-Modified-Since qualifier on HTTP GET operations is being ignored. Could this be true, and if so, can I make Tomcat pay attention to it? I could not find this issue addressed in the User's Guide nor the FAQ, nor fully well in the archive at mail-archive.com. Using the TcpTunnelGui included with SOAP, I captured the following exchange. Here is the GET request: GET /stylesheet/style.css HTTP/1.0 If-Modified-Since: Fri, 22 Jun 2001 19:18:56 GMT; length=2916 Connection: Keep-Alive User-Agent: Mozilla/4.75 [en] (Windows NT 5.0; U) Host: alphaspreit:9000 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: en,pdf Accept-Charset: iso-8859-1,*,utf-8 Cookie: JSESSIONID=0bzu6rxaj1 and here are the headers from a GET response (I strongly suspect, but am not 100% certain, it is the response to the GET above --- I've been having some trouble with the TcpTunneGui): HTTP/1.0 200 OK Content-Type: text/plain Content-Length: 2916 Last-Modified: Fri, 22 Jun 2001 19:18:56 GMT Servlet-Engine: Tomcat Web Server/3.2.2 (JSP 1.1; Servlet 2.2; Java 1.3.0; AIX 4.3 ppc; java.vendor=IBM Corporation)
Why are my HTTP resources treated differently than my HTTPS ones?
I have Tomcat 3.2.2 in standalone mode serving both HTTP and HTTPS. I have GIFs that appear on both the HTTP and the HTTPS pages. I am viewing my site with both Netscape 4.75 and IE 5.0 on Win 2K. Where the GIFs appear on HTTP pages, their create date, modification date, and file size are recorded in the browser's cache. Where the same GIFs appear on HTTPS pages (the GIFs themselves are, in this case, fetched from HTTPS URLs), none of those things is recorded in the browser's cache. Netscape's cache setting is Document in cache is compared to document on network: Every time, and IE's cache setting is Check for newer versions of stored pages: Automatically. Changing IE's cache setting to Every time you start Internet Explorer and flushing its cache makes no difference. When I change IE's cache setting to Every visit to the page, and flush its cache, then IE starts remembering the HTTPS GIFs' create date, modification date, and file size. For Netscape, changing the cache setting to Document in cache is compared to document on network: Once per session (and flushing the cache) causes the browser's cache to start remembering the create date, modification date, and file size (among other things) for the GIFs at HTTPS URLs. What causes this differential treatment of HTTP vs. HTTPS resources for some browser settings? Are there Tomcat configuration options that affect this? Thanks, Mike
incomplete output
I'm having problems with what looks like a lack of a flush somewhere inside tomcat. I'm running Tomcat 3.2.2b3 on RedHat Linux 6.2 with IBM's JDK 1.3. My web app is mildly complicated, with nested %@ include's and an invocation of RequestDispatcher.include(). The bytes returned to the browser are missing a range between somewhere inside a nested %@ include'd file and the start of the RequestDispatcher.include() output. Has anybody else seen bugs in this neck of the woods? Got any workarounds? I've looked at the release notes for 3.2.2, and don't see something that looks like this. Thanks, Mike
question on affinity for cookies
I have a web application served by Tomcat (currently 3.2.2b3). I've configured Tomcat to offer both a secured connector at HTTPS://host:8086/ and an unsecured version available at HTTP://host:8085/. My question is, should I expect my servlets to see the same session attributes when a client uses either of the two schemeport pairs? My experience is that it depends on the browser. For IE 5.0 on Win2K, the session attributes are common across the two prefixes; for Netscape 4.75 on the same client machine, the session attributes associated with one prefix are independent of the session attributes associated with the other. Which is correct, and what are my options for getting consistent behavior? Thanks, Mike
Re: Security Problem with Tomcat
The best description I have seen is at http://www.securityfocus.com/bid/2518. That's Bugtraq ID 2518. I was using Tomcat 3.2.1 on UNIX systems, and it had the bug. I have updated to Tomcat 3.2.2b2, and the bug is gone there. I am using Tomcat directly, not through Apache. I do not know whether those using Tomcat through Apache have a vulnerability. Mike
DeployedServices.ds
I'm upgrading from Tomcat 3.2.1 to 3.2.2b2. In my development installation, Tomcat is running OK, with no DeployedServices.ds extant. In my deployment installation, there is also no DeployedServices.ds, but I get this complaint: SOAP Service Manager: Unable to read 'DeployedServices.ds': assuming fresh start and then my SOAP clients fail like this: Generated fault: Fault Code = SOAP-ENV:Server Fault String = service 'urn:SOAPServer' unknown call returned with -5 How can this be? Should there be a DeployedServices.ds or not, and where? Thanks, Mike
Re: DeployedServices.ds
Never mind, I was confused by something else. DeployedServices.ds still needs to exist in Tomcat 3.2.2b2.
Re: Tomcat SSL Equifax
It's working for me. I'm not sure from your note whether you did the same thing, but what I did is to load the "certificate" (really a chain of two certs) for equifax into cacerts and then load the certificate for my site into the keystore used by tomcat. This left the keystore holding a chain of 3 certificates (the three mentioned above) under the alias "tomcat". Hope this helps, Mike
Re: Tomcat SSL Equifax
I won't call it "stupid", but you are still doing something wrong. In a little greater detail, here are instructions I wrote for the procedure I use (with Tomcat 3.2.1 and IBM JDK 1.3 currently): In response to a Certificate Signing Request, EquifaxSecure sends a mail message containing two "certificates". The first asserts the key binding requested, and is signed by EquifaxSecure. The second is actually a chain of two certificates: one asserts EquifaxSecure's key and is signed by Thawte, and the other is a self-signed certificate of Thawte's. I first tried `keytool -import` on the web server's certificate. This lead to a complaint about keytool not being able to establish trust in the certificate. I fixed this by: (1) using `keytool` to load, as a "new trusted certificate", the certificate-that's-actually-a-chain into $JAVA_HOME/jre/lib/security/cacerts on the web server machine, and (2) adding the "-trustcacerts" flag to the `keytool -import` of the web server's certificate. After that, `keytool -list` shows a chain of three certificates associated with the "tomcat" alias. Upon restarting Tomcat, I find that Netscape 4.75 and IE 5 on my Win 2K laptop both recognize the web site as secure without pestering the user --- provided there is only one key entry in the keystore used by Tomcat (when there is more than one key entry, Tomcat seems to pick one at random to use as the server's SSL/TLS identity). I hope this helps. Mike
Shouldn't Tomcat 3.2.1 decode the UTF-8 encoding of request parameters?
Consider a form that is encoded in UTF-8. Here's how it comes down: HTTP/1.0 200 OK Content-Type: text/html; charset=UTF-8 Servlet-Engine: Tomcat Web Server/3.2.1 (JSP 1.1; Servlet 2.2; Java 1.3.0; AIX 4.3 ppc; java.vendor=IBM Corporation) !DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/DTD/loose.dtd" html ... FORM METHOD=POST ACTION="/servlet/SusrReg" ... INPUT NAME="usr" TYPE=text SIZE="20" ... I fill in the "usr" field with a single character, U+201D, and submit. Here's how the submission goes up: POST /servlet/SusrReg HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-comet, application/pdf, */* Referer: http://9.2.43.70:8085/servlet/SusrReg Accept-Language: en-us Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) Host: 9.2.43.70:8085 Content-Length: 165 Connection: Keep-Alive Cookie: JSESSIONID=loj2w5hcz1 usr=%E2%80%9DB1=Submit In my servlet, I find the value of the request parameter named "usr" is a string of three characters: U+00E2, U+0080, U+009D. Should I be offended, or expect that the servlet should have to decode the UTF-8? I find the servlet spec v2.2 fairly silent on the issue, leading me to expect that the servlet container is supposed to handle the full parameter decoding. Thanks, Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat Not Shutting down properly
There was some earlier traffic about what causes this. I think it said you may succeed in shutting down Tomcat after trying the shutdown script a few times. You shouldn't have to do something as drastic as rebooting. At worst you'll have to find the offending processes yourself and `kill` them (I'd start with the leader). You can tell whether you've successfully stopped Tomcat in several ways. One is to get a fairly complete `ps` listing and grep through it for indicative things. Another is `netstat -a` and look for the LISTENer. Another revealing command is `lsof`. Good luck, Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Which Java keystore alias is used with Tomcat + SSL?
I had three key entries in my $HOME/.keystore, one with the alias "tomcat" and two with other aliases. I found Tomcat 3.2.1, with IBM JSSE 1.0.2, was not using the "tomcat" key entry but rather one of the others. I solved this problem by simply removing the others. I couldn't find any documentation on how to control Tomcat's selection of key entry. This might be another issue for the FAQ, or at least the SSL "how-to". Cheers, Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Is ANYONE doing this?? TC3.2.1 standalone + SSL + multiple instanceson multiple IP's
Dion, I am not doing the full combination you gave, but I *am* succeeding with my own app + SSL using Tomcat 3.2.1 in standalone mode (your problem #1). In my case, I am succeeding on AIX 4.3.3 with IBM's JDK 1.3 (and I'm failing on Linux, but that's another story, elsewhere in this mailing list). I am not using symlinks, so I can't speak to your exact circumstances. Have you tried restructuring your directories to be completely vanilla? A bit more complete details on your server.xml and directory/link structure would indeed be helpful to anyone trying to figure this out. I suspect you can expect a redirect anytime you ask for "foo" and expect to get "foo/index.html". Good luck, Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Re[2]: UserID and Passwd for the context Admin ???
I just tried what Patrik Beno said, and it worked for me. This question comes up again and again. I think it is truly a Frequently Asked Question (hint hint). Thanks, Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Can Tomcat support per-webapp users?
Is $TOMCAT_HOME/conf/tomcat-users.xml the only place where users passwords roles can be listed? Is there any way to administer these things on a per-webapp basis? Thanks, Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Charset issues with multiple includes?
I haven't looked into this issue closely yet, but may soon. I have some evidence that suggests that with Tomcat 3.1 on AIX 4.3.3, when I have a charset specified in an explicit HTML head, Netscape 4.75 pays attention to that instead of a different charset specified in the HTTP headers. Good luck, Mike Spreitzer
Re: Problems with Tomcat and XML4J/Xerces
Jason Voegele,
I found the following in the IBM-SOAP v1.2 Release Notes; it may apply to
your situation too:
IMPORTANT: Tomcat comes with an XML parser (lib/xml.jar) which has the DOM
level 1 interfaces. Even if you put
Xerces 1.0.3's xerces.jar in your classpath, the wrong interfaces are
found by any Java code running in Tomcat because
the shell script / batch file that runs Tomcat puts the user's classpath
at the end. So, you must edit tomcat.sh or tomcat.bin
in the bin/ directory and put xerces.jar at the BEGINING of the classpath
the script builds.
If you run startup.bat, then line 38 of tomcat.bat should look like this:
set CLASSPATH=path-to-xerces\xerces.jar;%CLASSPATH%;%cp%
If you run startup.sh, add the following after line 111:
CLASSPATH=path-to-xerces/xerces.jar:${CLASSPATH}
