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=30171>. 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=30171 RewriteRule: force external redirection is not automatic for non-SSL (http://) access [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From [EMAIL PROTECTED] 2004-07-18 15:38 ------- In your first test, the consistent 302 status code and http://www.apple.com for Location shows that Apache is returning the correct information to the browser. (IOW, Apache is doing the right thing.) I see no RFC 2616 restriction from changing the protocol across a redirect, so this is an Internet Explorer issue. You pointed out that the non-SSL test from the browser resulted in two access log lines; that means that the browser issued the request twice. I'm confused about your statement "Therefore, it shows it's not due to changing the protocol across a redirect." As far as I can tell, available data is consistent with the hypothesis that the unexpected browser behavior IS due to changing the protocol across a redirect: a) when you redirect to http, it works when the original protocol is http and fails when original protocol is https; i.e., same protocol okay, changed protocol not okay b) when you redirect to https (your latest test), it works when the original protocol is https and fails when the original protocol is http; i.e., same protocol okay, changed protocol not okay I suggest asking in user support mailing lists or newsgroups (see http://httpd.apache.org/lists.html#http-users) what has to be done to convince Internet Explorer to perform the automatic redirection, or if this is a permanent restriction. Your logging of status codes and Location header field values shows that Apache is sending it the appropriate information. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
