I sent this to [EMAIL PROTECTED]  I would welcome
comments on this proposal.

----

This is a suggestion for the next version of the servlet API.  I think
it solves a common problem, and I'd suggest that it's probably 100%
backward compatible.  It's also EASY.

PROBLEM: sendRedirect() and any other API calls that manipulate HTTP
response headers cannot be called after output is sent to the
ServletOutputStream.

SOLUTION:  Add an API call getHTTPResponseCode() (choose your own method
name). Then deprecate the sendRedirect() method.

The getHTTPResponseCode() method would allow the servlet developer to
examine the session, examine the HTTPRequest object, test parameters,
and otherwise determine what to do.  It could then return the proper
HTTP Response code (i.e. 404 Not found).

This would act as a sort of pre-condition to a doGet().

DISCUSSION: The sendRedirect() problem is more of an annoyance than a
PROBLEM, but it keeps coming up for new servlet developers.

This fix has several things to recommend it:

1. It's simple.
2. It would work.
3. It promotes better servlet design.
4. It would not break old servlets.
5. It's not going to frighten anyone.  It's optional, and servlet
developers can continue using the old deprecated sendRedirect() method
if they want.


Please consider this change for a future servlet API.  Servlets will be
around for a long time, and it would be better for everyone if we didn't
have new servlet developers in 2010 wondering why their call to
sendRedirect() didn't work.

Ben White
Centralogic Corp.

___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".

Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

Reply via email to