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

Quicksort implementation by using Java

 source: http://www.algolist.net/Algorithms/Sorting/Quicksort. The divide-and-conquer strategy is used in quicksort. Below the recursion step is described: 1st: Choose a pivot value. We take the value of the middle element as pivot value, but it can be any value(e.g. some people would like to pick the first element and do the exchange in the end) 2nd: Partition. Rearrange elements in such a way, that all elements which are lesser than the pivot go to the left part of the array and all elements greater than the pivot, go to the right part of the array. Values equal to the pivot can stay in any part of the array. Apply quicksort algorithm recursively to the left and the right parts - the previous pivot element excluded! Partition algorithm in detail: There are two indices i and j and at the very beginning of the partition algorithm i points to the first element in the array and j points to the last one. Then algorithm moves i forward, until an element with value greater or equal

Live - solving the jasper report out of memory and high cpu usage problems

I still can not find the solution. So I summary all the things and tell my boss about it. If any one knows the solution, please let me know. Symptom: 1.        The JVM became Out of memory when creating big consumption report 2.        Those JRTemplateElement-instances is still there occupied even if I logged out the system Reason:         1. There is a large number of JRTemplateElement-instances cached in the memory 2.     The clearobjects() method in ReportThread class has not been triggered when logging out Action I tried:      About the Virtualizer: 1.     Replacing the JRSwapFileVirtualizer with JRFileVirtualizer 2.     Not use any FileVirtualizer for cache the report in the hard disk Result: The japserreport still creating the a large number of JRTemplateElement-instances in the memory        About the work around below,      I tried: item 3(in below work around list) – result: it helps to reduce  the size of the JRTemplateElement Object        

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"/>