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]
