Filter access to response object [was Re: domain-wide sessioncookies?]
On Mon, 24 Mar 2003 14:10:59 -0800 (PST), Craig R. McClanahan [EMAIL PROTECTED] said: Sharing a session across virtual hosts violates the Servlet spec (Section 7.3 - HttpSession objects must be scoped at the application (or servlet context) level and Section 3.6 - Servlet contexts can not be shared across virtual hosts), so you should not really be surprised to find the logic for setting up a session cookie be hard coded in the manner you describe. Okay, you're right, that violates the spec. So please forget I asked (grin). Instead, what is now troubling me is that it seems that Tomcat adds HTTP headers to the response object *after* all filters have been applied. AFAICT, the spec does not explictly comment on this and so I'm assuming it is a detail left to the implementator. Here's my problem: - I have a single filter that essentially does: doFilter(...) do stuff to request object... chain.doFilter(..); do stuff to response object... } however, it seems that Tomcat adds response headers _after_ the filter, is there a reason for that? I'd like to manipulate *ALL* the headers in the response object with my filter... Adi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Filter access to response object [was Re: domain-wide sessioncookies?]
On Mon, 24 Mar 2003, Aditya wrote: Date: Mon, 24 Mar 2003 17:07:43 -0800 From: Aditya [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Filter access to response object [was Re: domain-wide session cookies?] On Mon, 24 Mar 2003 14:10:59 -0800 (PST), Craig R. McClanahan [EMAIL PROTECTED] said: Sharing a session across virtual hosts violates the Servlet spec (Section 7.3 - HttpSession objects must be scoped at the application (or servlet context) level and Section 3.6 - Servlet contexts can not be shared across virtual hosts), so you should not really be surprised to find the logic for setting up a session cookie be hard coded in the manner you describe. Okay, you're right, that violates the spec. So please forget I asked (grin). :-) Instead, what is now troubling me is that it seems that Tomcat adds HTTP headers to the response object *after* all filters have been applied. AFAICT, the spec does not explictly comment on this and so I'm assuming it is a detail left to the implementator. Here's my problem: - I have a single filter that essentially does: doFilter(...) do stuff to request object... chain.doFilter(..); do stuff to response object... } however, it seems that Tomcat adds response headers _after_ the filter, is there a reason for that? I'd like to manipulate *ALL* the headers in the response object with my filter... Since Tomcat adds its last headers when the response is committed (because otherwise they would not be able to be added), why not just add a call to: response.flushBuffer(); before the line that says: do stuff to response object... ? Adi Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Filter access to response object [was Re: domain-wide sessioncookies?]
On Mon, 24 Mar 2003 21:32:07 -0800 (PST), Craig R. McClanahan [EMAIL PROTECTED] said: On Mon, 24 Mar 2003, Aditya wrote: Here's my problem: - I have a single filter that essentially does: doFilter(...) do stuff to request object... chain.doFilter(..); do stuff to response object... } however, it seems that Tomcat adds response headers _after_ the filter, is there a reason for that? I'd like to manipulate *ALL* the headers in the response object with my filter... Since Tomcat adds its last headers when the response is committed (because otherwise they would not be able to be added), why not just add a call to: response.flushBuffer(); before the line that says: do stuff to response object... Maybe I wasn't clear -- I'd like to manipulate all the response headers at the point I say do stuff to response object... and if I call response.flushBuffer() right before that, I no longer can manipulate the headers in the response object (empirically verified under Tomcat 4.1.20). I must be missing something. Adi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
