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=31232>. 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=31232 ------- Additional Comments From [EMAIL PROTECTED] 2005-02-16 19:01 ------- (In reply to comment #10) > I do not agree with this patch in the general case. If a cookie is submitted, > we'll use it. I agree with that with one exception. This is not a general case, it's a use case where the (sub) context disables cookies and is expecting to use URL rewriting. The presence of the (ROOT) cookie forces a new session on each request since the URL rewriting is always overriden by the cookie, thus making the (sub) context unusable. Mixing cookies and URL rewriting is okay when the ROOT context doesn't use cookies (ie: /subA uses cookies, and /subB uses URL rewrite). Thought it would be easier to make the patch since this use case seems like a bug. See my comment #3 for additional reference. More workarounds that I thought of are: * create a host listening on a separate port. However this port may get blocked by firewalls since it's not port 80. * setting up a separate domain and use URL rewriting just in that domain. * don't use cookies at all. Not my favorite. I just don't want other people to experience the trouble that I had. If the decision is still a WONTFIX, then please add a note in the docs for the cookies attribute for Context that URL rewriting won't work for sub contexts if the ROOT context uses cookies. thanks. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
