DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19145>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19145 http to https redirect fails on non-standard ports ------- Additional Comments From [EMAIL PROTECTED] 2003-06-04 20:49 ------- Here is the response from telnet... HTTP/1.1 302 Moved Temporarily Pragma: No-cache Cache-Control: no-cache Expires: Thu, 01 Jan 1970 00:00:00 GMT Location: https://localhost:8443/hello1/greeting Content-Type: text/plain Content-Length: 0 Date: Wed, 04 Jun 2003 20:02:25 GMT Server: Apache Coyote/1.0 ...but I don't think that problem is with the initial redirect. When the initial redirect happens in IE, I am prompted to accept the self- signed certificate that I created for development. The problem happens after the subsequent redirect to the FORM-style authentication login page... Here is a little more background... The resource that I'm requesting is configured to be CONFIDENTIAL and require (FORM-based) authentication. So this is the request/response story-board that I would expect... 1a) Request: http://localhost:8080/hello1/greeting 1b) Response: 302, https://localhost:8443/hello1/greeting 2a) Request: https://localhost:8443/hello1/greeting 2b) Response: 302, https://localhost:8443/hello1/login.jsp 3a) Request: https://localhost:8443/hello1/login.jsp 3b) Response: 200 https://localhost:8443/hello1/login.jsp I am speculating about steps 2b, 3a, and 3b because I am not sure how to go about snooping HTTPS requests. (I tried using SSH a la PuTTY, but I couldn't get it to work.) It works if I disable either the auth-constraint or the transport-constraint (thus changing the story-board). It also works if I enter into the original story-board at 2a instead of 1a when both the auth-constraint and transport- constraint are enabled. It also works fine in IE if I use BASIC authentication instead of FORM authentication. It looks like the problem happens when IE receives two subsequent 302 responses. In the case of the second 302 response, the port specified in the response is not used by IE in the subsequent request; it uses the default port for the protocol. In other words, I suspect that Internet Explorer isn't using the port specified in 2b in its request of 3a, which would explain why having the second Coyote connector on port 443 allowed Internet Explorer to work. I should also add that I downloaded Mozilla Firebird and it was successfully redirected to the correct page. It definitely looks to be an Internet Explorer related bug. :-( Thanks for your help, Remy. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]