tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: RE:Tomcat - encodeURL does not encode https links on an HTTP requestOR any links on an HTTPS
Date Thu, 11 Oct 2001 17:42:58 GMT
Looking at HttpServletResponseFacade.isEncodeable, it seems that Tomcat is
requiring JSSE to be installed in order to encode a https: request (since
the protocol must be known to create a URL).
----- Original Message -----
From: "Hans Schmid" <>
To: <>
Sent: Monday, October 08, 2001 12:44 PM
Subject: RE:Tomcat - encodeURL does not encode https links on an HTTP
requestOR any links on an HTTPS

> Hi,
> we are experiencing exactly the same behaviour with Tomcat 3.3-rc1
> with mod_jk AJP1.3 Apache 1.3.19(Solaris 8 Sparc) when using SSL.
> Thats why we had to changed to <SessionId cookiesFirst="true"
> noCookies="false" />
> What we see using  <SessionId cookiesFirst="false" noCookies="true" />
> seems to result sometimes in weird behavior in a different area as well:
> Beeing in one Browser and entering data may cause this exact same data to
> displayed on a different Browser on a different machine. (Same
> We can not reproduce this every time but it happens way too often.
> We see the same sessionid appended to both URLs.
> This is really strange.
> Any Ideas?
> Hello,
> Noone seems to be able to answer this question (posted
> by other people) on the user's list, so I'm hoping
> eomeone on the dev list will be able to.
> I am running Apache 1.3.20 (w/ open ssl),
> JDK 1.3, J2EE1.2.1 and Tomcat 3.2.3.
> Session management works great with cookies, both
> across HTTP and HTTPS.  However, as soon as I turn
> cookies off, and use URL rewriting instead... URL
> rewriting ceases to work for HTTPS links (but still
> works fine on HTTP links) when I view the page under
> HTTP. Also, NOTHING is URL rewritten when the request
> was under HTTPS.
> I created a test page that displays
> request.getRequestedSessionId(),
> request.isRequestedSessionIdFromURL() and
> request.isRequestedSessionIdValid().  After clicking
> on a link on this test page that is a URL encoded
> link back to itself, I have an appended ;jsessionid on
> my HTTP request.  All URL encoded HTTP links ARE URL
> encoded with the same session id, BUT none of the same
> (but in HTTPS) links are.  getRequestedSessionId()
> shows the correct session id,
> isRequestedSessionIdFromURL() shows True, and
> isRequestedSessionIdValid() is True.
> Now, when I manually change the URL (WITH appended
> session ID) to HTTPS, NONE of the links are URL Encoded
> (http OR https).  However, getRequestedSessionId() STILL
> shows the correct session id,
> isRequestedSessionIdFromURL() STILL shows True, and
> isRequestedSessionIdValid() STILL is True.
> So I seem to be having two problems.  #1) REGARDLESS of
> protocol, HTTPS links are NEVER URL Encoded.  #2) Though
> HTTP links ARE URL Encoded when my request is in HTTP,
> they ARE NOT URL Encoded when my request is in HTTPS.
> Can someone shed some light on what is going on here?  I
> know (because of displaying getRequestedSessionId(),
> isRequestedSessionIdFromURL() and
> isRequestedSessionIDValid()) that my JSP page is getting
> all of the session information back, but it seems as if
> Tomcat doesn't know how to URL Encode properly for HTTPS
> links OR HTTPS requests.
> Thanks in advance!!
> Raiden Johnson
> p.s. I just upgraded to Tomcat 3.2.3, because I was having
> the same problem in 3.2.2
> Hans Schmid
> einsurance Agency AG
> Information Technology
> Bayerstra├če 33
> 80335 M├╝nchen
> Tel: +49-89-55292- 860
> Fax: +49-89-55292- 855
> eMail:


This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 

View raw message