You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by DirectXtras <po...@directxtras.com> on 2004/03/19 06:34:47 UTC

Autoreply: DO NOT REPLY [Bug 27705] - HttpServletResponse.encodeURL does not work correctly with https

Hello,

Due to the increased volume of SPAM this mailbox has been closed.

Please contact us via http://www.directxtras.com/ContactUS.asp

We apology for the inconvenience.

Best Regards,
--
The DirectXtras Team
---------------------------------------------------------------------
DirectXtras - Xtra Power for Director and Authorware -
              http://www.directxtras.com
Sites with something to say - http://www.SpeaksForItself.com
---------------------------------------------------------------------


Your message reads:

Received: from mail.apache.org (unverified [208.185.179.12]) by mail2.intermedia.net
 (Rockliffe SMTPRA 4.5.6) with SMTP id <B0...@mail2.intermedia.net> for <po...@directxtras.com>;
 Thu, 18 Mar 2004 21:34:47 -0800
Received: (qmail 64198 invoked by uid 500); 19 Mar 2004 05:34:25 -0000
Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <ma...@jakarta.apache.org>
List-Subscribe: <ma...@jakarta.apache.org>
List-Help: <ma...@jakarta.apache.org>
List-Post: <ma...@jakarta.apache.org>
List-Id: "Tomcat Developers List" <tomcat-dev.jakarta.apache.org>
Reply-To: "Tomcat Developers List" <to...@jakarta.apache.org>
Delivered-To: mailing list tomcat-dev@jakarta.apache.org
Received: (qmail 64144 invoked from network); 19 Mar 2004 05:34:25 -0000
Received: from unknown (HELO exchange.sun.com) (192.18.33.10)
  by daedalus.apache.org with SMTP; 19 Mar 2004 05:34:25 -0000
Received: (qmail 16107 invoked by uid 50); 19 Mar 2004 05:35:09 -0000
Date: 19 Mar 2004 05:35:09 -0000
Message-ID: <20...@nagoya.betaversion.org>
From: bugzilla@apache.org
To: tomcat-dev@jakarta.apache.org
Cc:
Subject: DO NOT REPLY [Bug 27705]  - 
    HttpServletResponse.encodeURL does not work correctly with https
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=27705>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=27705

HttpServletResponse.encodeURL does not work correctly with https

pyropunk@usa.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |



------- Additional Comments From pyropunk@usa.net  2004-03-19 05:35 -------
I have read the specs (Servlet API version 2.3 and 2.4) and I must disagree 
with you. All that the spec says is that a webapp lives at a PATH on a server. 
This does not mean that when the server part changes that it _necessarily_ is a 
different webapp. All three the cases I mentioned in the bug could end up in 
the same webapp.
1) https - very likely will end up in the same webapp and I think addresses 
that have the same structure except for a protocol change must be encoded, 
otherwise you have no way of passing the user's session to a secure site.
2) port - less likely to end up in the same webapp, but it depends on the 
config of the connector between the web server and Tomcat.
3) server name - unlikley but may still end up in the same webapp because the 
web server may have virtual hosts all pointing to the same webapp.

Please explain, why Tomcat has chosen to interpret the spec in such a 
restrictive way instead of looking at the problem logically.

>From what I have read in some of the newsgroups is that a lot of people had to 
do their own encodeURL because Tomcat's implementation is too restrictive.

PS: I realize you may have a lot of experience with this, but is is annoying if 
these "quirks" are not documented anywhere and one then usually spends a lot of 
time debugging a "feature".

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org