DO NOT REPLY [Bug 18361] - IIS doesn't like ;jsessionid within uri
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=18361. 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=18361 IIS doesn't like ;jsessionid within uri --- Additional Comments From [EMAIL PROTECTED] 2003-03-26 14:17 --- Another solution: Don't use IIS. Use Apache's http server to front Tomcat. We did this on our win2k servers and even noticed a marked speed improvement (and that's with only using the mod_proxy). Plus we were finally able to use mod_gzip! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18361] - IIS doesn't like ;jsessionid within uri
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=18361. 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=18361 IIS doesn't like ;jsessionid within uri --- Additional Comments From [EMAIL PROTECTED] 2003-03-26 14:45 --- This one is out of question. The whole story happens in a multi-thousand-employees company - the inert ion of such a big animal is enormous. Actually the applications servers and web servers do not belong to the same department. We have absolutely no influence on what web server do the others choose, besides they have software relying on IIS that must be used. The good (and surprising) is that they take apache into account at all, just that it will take some time until they have tested it and found replacements for all the stuff they have. And waiting until they migrate to apache is another solution that wont work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18361] - IIS doesn't like ;jsessionid within uri
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=18361. 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=18361 IIS doesn't like ;jsessionid within uri [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-03-26 14:58 --- IIS doesn't handle forwarding very well in the first place. This is an IIS limitation - not a tomcat limitation. You could try forwarding by path (I'm assuming you are using BEA's wlforward ISAPI plugin). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18361] - IIS doesn't like ;jsessionid within uri
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=18361. 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=18361 IIS doesn't like ;jsessionid within uri --- Additional Comments From [EMAIL PROTECTED] 2003-03-26 16:01 --- I have never stated that this were a Tomcat limitation, I was just looking for a feedback from Tomcat community - and I got it. Thats okay. OTOH IIS with its limitations is fact of life, organisations like mine also. In this case BEA has chosen a solution thats easy for its customers, even if it doesnt follow the standard and we were happy they did it - dont take me wrong, I now Tomcat is open source and nobody gets paid for the working on it, contrary to people working on BEA WebLogic. If the migration starts and the only solution my boss accepts would be to patch Tomcat, would you accept a change (I already submitted patches for Eclipse for that matter)? Or would you say its non-standard so we wont use it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
