"An included page only has access to the JspWriter object and it cannot set headers. This precludes invoking methods like setCookie(). Attempts to invoke these methods will be ignored. The constraint is equivalent to the one imposed on the include() method of the RequestDispatcher class."
So jsp:include also has all the same restrictions imposed by RequestDispatcher.include().
As for th 302 errors, from the RFC: http://www.ietf.org/rfc/rfc2616.txt ... The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
I paraphrase as its nice to present some body content in your page since browsers/agents do have the option of displaying/parsing the body for some context before following the redirect.
-Tim
Geoff Coffey wrote: [...]
I would expect sendRedirect() to
abort the response anyway, although someone may have a good reason to include content in a 302 response. A forward, on the other hand, does abort the response, so it is even more arbitrary that forwards don't work in includes. It seems like this is a case where a weakness in the model at a low level rears its head at the very highest level (JSP), which is, IMO, a bad thing. And the docs don't seem clear on this point at all. We only were able to confirm that redirects and forwards don't work in includes by examining the generated .java files and reading the docs on the servlet stuff. The JSP docs don't seem to mention it (I may be missing it...)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
