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=13441>. 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=13441 WebApp Connector not writing status code properly on HTTP/1.1 responses Summary: WebApp Connector not writing status code properly on HTTP/1.1 responses Product: Tomcat 4 Version: 4.1.12 Platform: Other URL: http://web.dotinc.net/dynamic/dapps/test OS/Version: Linux Status: NEW Severity: Critical Priority: Other Component: Connector:Webapp AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] All of our dynamic pages generated from Tomcat 4.1.12 hooked into our Apache server (2.0.40) via mod_webapp are now broken when viewed with IE 6 (upgraded to Service Pack 1). It seems that static pages from the server work OK but all of the dynamic pages are broken. When the same pages are viewed through mod_rewrite by proxying directly to port 8080 on Tomcat, they work fine. It seems that the only difference between the pages that work and those that don't is the status response code for the pages that are served properly. For the pages that work, the status line in the response header is HTTP/1.1 200 OK for the WebApp served pages, it is HTTP/1.1 OK This URL worked OK with the previous version of IE but breaks IE 6 SP 1. This problem does not affect loading of these dynamic pages on any Netscape browsers I have tried but Netscape 4.77 pops up a dialog saying "Unknown Status Code 0!" before loading the page. I think this is occuring because it is trying to parse the "OK" as a number because the 200 status code is missing. This problem started occurring when we upgraded both Tomcat and the Apache server recently on our main Linux Web server and a client testing another dynamic site encountered this problem the day after the switchover occurred. p.s. the mod_rewrite solution mentioned above serves as a viable workaround to the problem but and redirects would have to be modified to be absolute URLs or possible changed to server HTML with meta tag refreshes. Hope this description and sample URL help fix the bug right away. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>