Skip to main content

Servlet - Response

A typical response looks like this:
HTTP/1.1 200 OK
Context-Type: text/html
Header2: ..
HeaderN;..
(Blank Line)
<!DOCTYPE ...>
<HTML>
<HEAD>..</HEAD>
<BODY>
...
</BODY>
</HTML>

STATUS CODES:

100–199
Codes in the 100s are informational, indicating that the client should
respond with some other action.
• 200–299
Values in the 200s signify that the request was successful.
• 300–399
Values in the 300s are used for files that have moved and usually
include a Location header indicating the new address.
• 400–499
Values in the 400s indicate an error by the client.
• 500–599
Codes in the 500s signify an error by the server.

Details:

(OK)
A value of 200 (SC_OK) means that everything is fine; the document follows for
GET and POST requests. This status is the default for servlets; if you don’t use
setStatus, you’ll get 200.
202 (Accepted)
A value of 202 (SC_ACCEPTED) tells the client that the request is being acted
upon but processing is not yet complete.
204 (No Content)
A status code of 204 (SC_NO_CONTENT) stipulates that the browser should
continue to display the previous document because no new document is available.
This behavior is useful if the user periodically reloads a page by pressing
the Reload button and you can determine that the previous page is already
up-to-date.
205 (Reset Content)
A value of 205 (SC_RESET_CONTENT) means that there is no new document
but the browser should reset the document view. Thus, this status code is used
to instruct browsers to clear form fields. It is new in HTTP 1.1.
301 (Moved Permanently)
The 301 (SC_MOVED_PERMANENTLY) status indicates that the requested document
is elsewhere; the new URL for the document is given in the Location
response header. Browsers should automatically follow the link to the new
URL.
302 (Found)
This value is similar to 301, except that in principle the URL given by the
Location header should be interpreted as a temporary replacement, not a
permanent one. In practice, most browsers treat 301 and 302 identically. Note:
in HTTP 1.0, the message was Moved Temporarily instead of Found, and
the constant in HttpServletResponse is SC_MOVED_TEMPORARILY, not
the expected SC_FOUND.


(Not Modified)
When a client has a cached document, it can perform a conditional request by
supplying an If-Modified-Since header to signify that it wants the document
only if it has been changed since the specified date. A value of 304
(SC_NOT_MODIFIED) means that the cached version is up-to-date and the client
should use it. Otherwise, the server should return the requested document
with the normal (200) status code. Servlets normally should not set this status
code directly. Instead, they should implement the getLastModified
method and let the default service method handle conditional requests
based upon this modification date. For an example, see the LotteryNumbers
servlet in Section 3.6 (The Servlet Life Cycle).
307 (Temporary Redirect)
The rules for how a browser should handle a 307 status are identical to those
for 302. The 307 value was added to HTTP 1.1 since many browsers erroneously
follow the redirection on a 302 response even if the original message is a
POST. Browsers are supposed to follow the redirection of a POST request only
when they receive a 303 response status. This new status is intended to be
unambiguously clear: follow redirected GET and POST requests in the case of
303 responses; follow redirected GET but not POST requests in the case of 307
responses. This status code is new in HTTP 1.1.
400 (Bad Request)
A 400 (SC_BAD_REQUEST) status indicates bad syntax in the client request.
401 (Unauthorized)
A value of 401 (SC_UNAUTHORIZED) signifies that the client tried to access a
password-protected page but that the request did not have proper identifying

information in the Authorization header. The response must include a
WWW-Authenticate header. For details, see the chapter on programmatic
Web application security in Volume 2 of this book.
403 (Forbidden)
A status code of 403 (SC_FORBIDDEN) means that the server refuses to supply
the resource, regardless of authorization. This status is often the result of bad
file or directory permissions on the server.

404 (Not Found)
The infamous 404 (SC_NOT_FOUND) status tells the client that no resource could
be found at that address. This value is the standard “no such page” response. It is
such a common and useful response that there is a special method for it in the
HttpServletResponse class: sendError("message"). The advantage of
sendError over setStatus is that with sendError, the server automatically
generates an error page showing the error message. 404 errors need not
merely say “Sorry, the page cannot be found.” Instead, they can give information
on why the page couldn’t be found or supply search boxes or alternative
places to look. The sites at www.microsoft.com and www.ibm.com have particularly
good examples of useful error pages (to see them, just make up a nonexistent
URL at either site). In fact, there is an entire site dedicated to the good, the
bad, the ugly, and the bizarre in 404 error messages: http://www.plinko.net/
404/. We find http://www.plinko.net/404/links.asp?type=cat&key=13 (amusing
404 error messages) particularly funny.
Unfortunately, however, the default behavior of Internet Explorer in version 5
and later is to ignore the error page you send back and to display its own static
(and relatively useless) error message, even though doing so explicitly contradicts
the HTTP specification. To turn off this setting, go to the Tools menu,
select Internet Options, choose the Advanced tab, and make sure the “Show
friendly HTTP error messages” box is not checked. Regrettably, few users are
aware of this setting, so this “feature” prevents most users of Internet Explorer
from seeing any informative messages you return. Other major browsers and
version 4 of Internet Explorer properly display server-generated error pages.






Fortunately, it is relatively uncommon for individual servlets to build their own
404 error pages. A more common approach is to set up error pages for an
entire Web application; see Section 2.11 (Web Applications: A Preview) for
details.
405 (Method Not Allowed)
A 405 (SC_METHOD_NOT_ALLOWED) value signifies that the request method
(GET, POST, HEAD, PUT, DELETE, etc.) was not allowed for this particular
resource. This status code is new in HTTP 1.1.
415 (Unsupported Media Type)
A value of 415 (SC_UNSUPPORTED_MEDIA_TYPE) means that the request had
an attached document of a type the server doesn’t know how to handle. This
status code is new in HTTP 1.1.
417 (Expectation Failed)
If the server receives an Expect request header with a value of
100-continue, it means that the client is asking if it can send an attached
document in a follow-up request. In such a case, the server should either
respond with this status (417) to tell the browser it won’t accept the document
or use 100 (SC_CONTINUE) to tell the client to go ahead. This status code is
new in HTTP 1.1.
500 (Internal Server Error)
500 (SC_INTERNAL_SERVER_ERROR) is the generic “server is confused” status
code. It often results from CGI programs or (heaven forbid!) servlets that
crash or return improperly formatted headers.
501 (Not Implemented)
The 501 (SC_NOT_IMPLEMENTED) status notifies the client that the server
doesn’t support the functionality to fulfill the request. It is used, for example,
when the client issues a command like PUT that the server doesn’t support.
503 (Service Unavailable)
A status code of 503 (SC_SERVICE_UNAVAILABLE) signifies that the server
cannot respond because of maintenance or overloading. For example, a servlet
might return this header if some thread or database connection pool is currently
full. The server can supply a Retry-After header to tell the client
when to try again.


505 (HTTP Version Not Supported)
The 505 (SC_HTTP_VERSION_NOT_SUPPORTED) code means that the server
doesn’t support the version of HTTP named in the request line. This status
code is new in HTTP 1.1.

Comments

Popular posts from this blog

Stretch a row if data overflows in jasper reports

It is very common that some columns of the report need to stretch to show all the content in that column. But  if you just specify the property " stretch with overflow' to that column(we called text field in jasper report world) , it will just stretch that column and won't change other columns, so the row could be ridiculous. Haven't find the solution from internet yet. So I just review the properties in iReport one by one and find two useful properties(the bold highlighted in example below) which resolve the problems.   example:
<band height="20" splitType="Stretch"> <textField isStretchWithOverflow="true" pattern="" isBlankWhenNull="true"> <reportElement stretchType="RelativeToTallestObject" mode="Opaque" x="192" y="0" width="183" height="20"/> <box leftPadding="2"> <pen lineWidth="0.25"/> …

JasperReports - Configuration Reference

Spring - Operations with jdbcTemplate

This class manages all the database communication and exception handling using a java.sql.Connection that is obtained from the provided DataSource. JdbcTemplate is a stateless and threadsafe class and you can safely instantiate a single instance to be used for each DAO.


Use of Callback Methods
JdbcTemplate is based on a template style of programming common to many other parts of Spring. Some method calls are handled entirely by the JdbcTemplate, while others require the calling class to provide callback methods that contain the implementation for parts of the JDBC workflow. This is another form of Inversion of Control. Your application code hands over the responsibility of managing the database access to the template class. The template class in turn calls back to your application code when it needs some detail processing filled in. These callback methods are allowed to throw a java.sql.SQLException, since the framework will be able to catch this exception and use its built-in excepti…