You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Caldarale, Charles R" <Ch...@unisys.com> on 2009/01/28 16:09:40 UTC

RE: Servlet 2.5 and RequestDispatcher.include + Response.setHeader, invalid?

> From: Ken Johanson [mailto:tomcat-user@kensystem.com]
> Subject: Servlet 2.5 and RequestDispatcher.include +
> Response.setHeader, invalid?
>
> It's my understanding that servlet 2.5 loosened the requirement that a
> included/callee Servlet (and JSP?) cannot set the resp headers/status,
> and should now be able to set them if not already committed.

Why do you think your "understanding" would override an explicit statement in the spec?  Here's the exact text from SRV.8.3 of the servlet spec version 2.5mr6:

"It cannot set headers or call any method that affects the headers of the response, with the exception of the HttpServletRequest.getSession() and HttpServletRequest.getSession(boolean) methods. Any attempt to set the headers must be ignored, and any call to HttpServletRequest.getSession() or HttpServletRequest.getSession(boolean) that would require adding a Cookie response header must throw an IllegalStateException if the response has been committed."

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Servlet 2.5 and RequestDispatcher.include + Response.setHeader, invalid?

Posted by Ken Johanson <to...@kensystem.com>.
Caldarale, Charles R wrote:
>> From: Ken Johanson [mailto:tomcat-user@kensystem.com]
>> Subject: Re: Servlet 2.5 and RequestDispatcher.include +
>> Response.setHeader, invalid?
>>
>> Do you know if that rule applies only to the Request
>> object passed by the RequestDispatcher, or should the
>> container also prevent this if the original Request
>> was purposely passed into the dispatched handler, in
>> order to allow it to set headers/status?
> 
> Good question; sounds like yet another ambiguity in the spec.  I'd have to dig through the code to find out how Tomcat currently handles that situation, and that's not likely to happen today.  Hopefully one of the committers can answer that.
> 
>  - Chuck
> 
> 

Before someone decides to commit code that "fixes" this, I would submit 
that the behavior should remain as-is; because if the calling servlet is 
purposefully conveying the original request object to a dispatched 
handler, then the callee should be allowed to set them. There are no 
doubt others who rely on this behavior right now, since there are some 
cases in where forward() or filters are not suitable. I too am looking 
for predictability / stability...

-k



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Servlet 2.5 and RequestDispatcher.include + Response.setHeader, invalid?

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Ken Johanson [mailto:tomcat-user@kensystem.com]
> Subject: Re: Servlet 2.5 and RequestDispatcher.include +
> Response.setHeader, invalid?
>
> Do you know if that rule applies only to the Request
> object passed by the RequestDispatcher, or should the
> container also prevent this if the original Request
> was purposely passed into the dispatched handler, in
> order to allow it to set headers/status?

Good question; sounds like yet another ambiguity in the spec.  I'd have to dig through the code to find out how Tomcat currently handles that situation, and that's not likely to happen today.  Hopefully one of the committers can answer that.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Servlet 2.5 and RequestDispatcher.include + Response.setHeader, invalid?

Posted by Ken Johanson <to...@kensystem.com>.
Caldarale, Charles R wrote:

>> It's my understanding that servlet 2.5 loosened the requirement that a
>> included/callee Servlet (and JSP?) cannot set the resp headers/status,
>> and should now be able to set them if not already committed.
> 
> Here's the exact text from SRV.8.3 of the servlet spec version 2.5mr6:
> 
> "It cannot set headers or call any method that affects the headers of the response, with the exception of the HttpServletRequest.getSession() and HttpServletRequest.getSession(boolean) methods. Any attempt to set the headers must be ignored, and any call to HttpServletRequest.getSession() or HttpServletRequest.getSession(boolean) that would require adding a Cookie response header must throw an IllegalStateException if the response has been committed."
> 
>  - Chuck
> 

Thanks for replying Chuck. Do you know if that rule applies only to the 
Request object passed by the RequestDispatcher, or should the container 
also prevent this if the original Request was purposely passed into the 
dispatched handler, in order to allow it to set headers/status?

Ken



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org