DO NOT REPLY [Bug 34245] - HttpServletRequest.getSession() does not set up cookie after HttpServletResponse.reset() was called
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=34245. 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=34245 --- Additional Comments From [EMAIL PROTECTED] 2005-03-30 22:38 --- Created an attachment (id=14596) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14596action=view) The WAR file that demonstrates the problem -- 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]
DO NOT REPLY [Bug 34245] - HttpServletRequest.getSession() does not set up cookie after HttpServletResponse.reset() was called
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=34245. 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=34245 [EMAIL PROTECTED] changed: What|Removed |Added Severity|major |normal --- Additional Comments From [EMAIL PROTECTED] 2005-03-30 23:05 --- This looks extremely suspicious. I will test it, though, since you provide a test case. -- 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]
DO NOT REPLY [Bug 34245] - HttpServletRequest.getSession() does not set up cookie after HttpServletResponse.reset() was called
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=34245. 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=34245 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-03-30 23:13 --- I thought about it some more, and the behavior is actually understandable. reset clears the whole HTTP body, including cookies. We only set the session cookie when creating the session. The session will not be cleared by reset. There's also no reason at all to set a cookie every time you call req.getSession(): you should invalidate the session yourself after the reset call. As a result, the behavior you want will not be supported. Please do not reopen the report (if you do, I will close it again as WONTFIX without further comments). -- 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]
DO NOT REPLY [Bug 34245] - HttpServletRequest.getSession() does not set up cookie after HttpServletResponse.reset() was called
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=34245. 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=34245 --- Additional Comments From [EMAIL PROTECTED] 2005-03-30 23:53 --- I would argue that the current behavior does not completely comply to the Servlet spec. The documentations on HttpServletRequest.getSession() says: Returns the current session associated with this request, or if the request does not have a session, creates one. And the documentation for ServletResponse.reset() says: Clears any data that exists in the buffer as well as the status code and headers. If the response has been committed, this method throws an IllegalStateException. There is nothing said about if reset() is called, session cookie will not be added to the header. The fact that I called getSession() after reset() was call ed but no session cookie was set, indicates an implementation deficiency. As a user, I shouldn'd care when the cookie is actually set in Tomcat's implementation and why it didn't do it after reset() was called. All I see is that I asked the Servlet container to set up a session but it was not done. If a web application is based on a framework (e.g. Struts), in some cases, there may be headers set up automatically by the framework before the application will get a chance to process request. In the case of Struts, for example, a developer can configure it to set up a default content type of say text/html;charset=UTF-8 for most of its pages. The problem I have ran into with Struts and Tomcat is that once that's set, calling response.setContentType(application/pdf) will not clear the charset=UTF-8 part in the response header, because I believe at least with Tomcat 4.x, the charset is stored in a seperate variable. Now when Adobe Acrobat Reader (or maybe the browser) gets the content type applicaton/pdf;charset=UTF-8, it does not know how to handle it in some cases and the user would get a blank screen in their browser. Once could argue it's Adobe's responsibility to support a content type with charset specified, but I just wish if everyone in this complicated integration tries to make their piece more reasonable, our developers' job will be a lot easier. -- 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]
DO NOT REPLY [Bug 34245] - HttpServletRequest.getSession() does not set up cookie after HttpServletResponse.reset() was called
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=34245. 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=34245 --- Additional Comments From [EMAIL PROTECTED] 2005-03-30 23:58 --- Calling reset clears all cookies which have been previously set (as cookies are set through HTTP headers in the response, which are cleared - something which I didn't realize right away in comment #2). You know, there are lots of ways the user can screw things up, and it's not possible to prevent everything. -- 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]
DO NOT REPLY [Bug 34245] - HttpServletRequest.getSession() does not set up cookie after HttpServletResponse.reset() was called
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=34245. 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=34245 --- Additional Comments From [EMAIL PROTECTED] 2005-03-31 00:09 --- Agreed. There is always ways to screw things up in any given system. In my case, I did not try to screw anything up. I was trying to follow the Servlet documentation to find a solution for my PDF problem. I really wasn't comfortable calling reset() but I could not find any other way to clear the charset field. For now, I had to change the configuration in Struts so that charset=UTF-8 is not included. Maybe I should put another bug report for Tomcat for not clearing the charset field when response.setContentType() is called without charset specified. -- 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]
DO NOT REPLY [Bug 34245] - HttpServletRequest.getSession() does not set up cookie after HttpServletResponse.reset() was called
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=34245. 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=34245 --- Additional Comments From [EMAIL PROTECTED] 2005-03-31 00:16 --- From what you told me, is it correct to deduce the following: In the same request/response scope, if I start out by creating a session and later on invalidate it and then create a new one, I would get two JSESSION cookies set up in the response header? I still think the cookie should only be added when the response is about to be committed. -- 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]
