List of http status codes
1**: Request received, continue processing
2**: The operation is successfully received, analyzed and accepted
3**: further processing is required to complete this request
4**: The request contained an incorrect syntax or could not be completed
5**: The server failed to execute a perfectly valid request
100 - client must continue to issue requests
101——The client requires the server to convert the HTTP protocol version according to the request
200 - transaction successful
201 - Prompt to know the URL of the new file
202 - Accepted and processed, but processing not complete
203 - The returned information is uncertain or incomplete
204——The request was received, but the return information is empty
205——The server has completed the request, and the user agent must reset the currently viewed file
206——The server has completed the GET request of some users
300 - The requested resource is available in multiple places
301 - delete request data
302——The requested data was found at another address
303——Suggest customers to visit other URLs or access methods
304 - The client has performed a GET, but the file has not changed
305 - The requested resource must be obtained from the address specified by the server
306——The code used in the previous version of HTTP is no longer used in the current version
307——Affirm the temporary deletion of the requested resource
400 - Bad Request, such as syntax error
401 - request authorization failed
402 - keep valid ChargeTo header response
403 - request not allowed
404 - No file, query or URL found
405 - The method defined by the user in the Request-Line field is not allowed
406——According to the Accept message sent by the user, the requested resource is inaccessible
407 - similar to 401, the user must first be authorized on the proxy server
408 - The client did not complete the request within the time specified by the user
409 - The request cannot be completed for the current resource state
410 - The resource no longer exists on the server and there are no further reference addresses
411 - The server rejects the request for the user-defined Content-Length attribute
412 - One or more request header fields are incorrect in the current request
413 - The requested resource is larger than the size allowed by the server
414 - The requested resource URL is longer than the length allowed by the server
415 - The requested resource does not support the requested item format
416——The request contains the Range request header field, and there is no range indication value in the current request resource range, the request
Also does not contain the If-Range request header field
417——The server does not meet the expected value specified in the request Expect header field. If it is a proxy server, it may be the following
The primary server cannot fulfill the request
500 - The server generated an internal error
501 - The server does not support the requested function
502 - The server is temporarily unavailable, sometimes to prevent system overload
503 - Server overloaded or suspended for maintenance
504——The gateway is overloaded, the server uses another gateway or service to respond to the user, and the waiting time is set to a longer value
505 - The server does not support or refuses to support the HTTP version specified in the request header
The complete HTTP 1.1 specification is from RFC 2616, which you can view online at http://www.rfc-editor.org/. HTTP 1.1 status codes are marked as new because many browsers only support HTTP 1.0. You should only send status codes to clients that support HTTP 1.1. The supported protocol version can be checked by calling request.getRequestProtocol.
The rest of this section describes the status codes in HTTP 1.1 in detail. These status codes are divided into five broad categories:
100-199 are used to specify certain actions that the client should take accordingly.
200-299 are used to indicate a successful request.
300-399 are used for files that have been moved and are often included in the location header to specify new address information.
400-499 are used to indicate client errors.
500-599 are for support server errors.
Constants in HttpServletResponse represent status codes associated with different standard messages. In the servlet program, you will use the identification of these constants more to use the status code. For example: you generally use response.setStatus(response.SC_NO_CONTENT) instead of response.setStatus(204), because the latter is not easy to understand and is prone to errors. However, you should note that the server allows slight changes to the message, while the client only pays attention to the numeric value of the status code. So the server might just return HTTP/1.1 200 instead of HTTP/1.1 200 OK.
100 (Continue/Continue)
If the server receives a request with 100-continue in the header, it means that the client is asking if it can send the attachment in a subsequent request. In this case, the server uses 100 (SC_CONTINUE) to allow the client to continue or 417 (Expectation Failed) to tell the client that it does not agree to accept the attachment. This status code is new in HTTP 1.1.
101 (Switching Protocols/conversion protocol)
The 101 (SC_SWITCHING_PROTOCOLS) status code means that the server will change to a different protocol according to the header information on it. This is new in HTTP 1.1.
200 (OK/Normal)
200 (SC_OK) means everything is OK. Generally used for corresponding GET and POST requests. This status code is the default for servlets; if you do not call the setStatus method, you will get 200.
201 (Created/created)
201 (SC_CREATED) indicates that the server created a new document in response to the request; its URL should be given in the Location header.
202 (Accepted/Accept)
202 (SC_ACCEPTED) tells the client that the request is being executed, but not yet processed.
203 (Non-Authoritative Information/unofficial information)
Status code 203 (SC_NON_AUTHORITATIVE_INFORMATION) means that the document was returned normally, but some response header information may be incorrect because a copy of the document is being used. This is new in HTTP 1.1.
204 (No Content/no content)
In the absence of a new document, 204 (SC_NO_CONTENT) ensures that the browser continues to display the previous document. These status codes are very useful for users to periodically reload a page, and you can determine whether the previous page has been updated. For example, a servlet might do the following:
int pageVersion =Integer.parseInt(request.getParameter("pageVersion"));
if (pageVersion >;= currentVersion) {
response.setStatus(response.SC_NO_CONTENT);
} else {
// Create regular page
}
However, this approach will work for pages that are automatically reloaded via the Refresh response header or equivalent HTML markup, as it will return a 204 status code to stop future reloads. But JavaScript-based auto-reload still needs to work in this case. You can read the detailed discussion in section 7.2 (HTTP 1.1 Response Headers and Their Meaning/HTTP 1.1 Response Headers and Their Meaning) of this book.
205 (Reset Content/Reset Content)
Reset content 205 (SC_RESET_CONTENT) means that although there is no new document, the browser wants to reset the document display. This status code is used to force the browser to clear form fields. This is new in HTTP 1.1.
206 (Partial Content/partial content)
206 (SC_PARTIAL_CONTENT) is sent when the server completes a partial request that includes a Range header. This is new in HTTP 1.1.
300 (Multiple Choices/Multiple Choices)
300 (SC_MULTIPLE_CHOICES) indicates that the requested document can be found in multiple places and will be listed in the returned document. If the server has a preference set, the preference will be listed in the location response header.
301 (Moved Permanently)
The 301 (SC_MOVED_PERMANENTLY) status means that the requested document is elsewhere; the new URL of the document will be given in the Location response header. The browser will automatically connect to the new URL.
302 (Found/found)
Somewhat similar to 301, except that the URL given in the location header should be understood as a temporary exchange address rather than a permanent one. Note: In HTTP 1.0, the message is temporarily moved (Moved Temporarily) instead of being found, so the constant in HttpServletResponse is SC_MOVED_TEMPORARILY instead of SC_FOUND as we thought.
Notice
The constant for status code 302 is SC_MOVED_TEMPORARILY instead of SC_FOUND.
Status code 302 is useful because the browser automatically connects to the new URL given in the response header. This is very useful, and there is a dedicated method for this - sendRedirect. Using response.sendRedirect(url) has several advantages over calling response.setStatus(response.SC_MOVED_TEMPORARILY) and response.setHeader("Location", url). First, the response.sendRedirect(url) method is obviously simpler and easier. Second, the servlet automatically creates a page to save the connection for display by browsers that cannot automatically redirect. Finally, in servlet version 2.2 (the version in J2EE), sendRedirect can handle relative paths, which are automatically converted to absolute paths. But you can only use absolute paths in version 2.1.
If you redirect the user to another page on the site, you pass the URL using the encodeURL method on HttpServletResponse. Doing this prevents the constant use of session tracking based on URL rewriting. URL rewriting is a way to track users on your website who don't use cookies. This is accomplished by appending path information to the end of each URL, but the servlet session tracking API takes care of these details automatically. Session tracking is discussed in Chapter 9, and getting into the habit of using encodeURL will make adding session tracking a lot easier later.
core skills
If you're redirecting users to other pages on your site, it's much better to plan ahead for session tracking with response.sendRedirect(response.encodeURL(url)) than just calling response.sendRedirect(url) .
This status code is sometimes used interchangeably with 301. For example, if you access http://host/~user by mistake (incomplete path information), some servers will reply with a 301 status code and some will reply with a 302. Technically, the browser is just assumed to automatically redirect if the initial request was a GET. See the discussion of status code 307 for more details.
303 (See Other/See other information)
This status code is similar to 301, 302, except that if the original request was a POST, then the new document (given in the Location header) is retrieved with a GET. This status code is new in HTTP 1.1.
304 (Not Modified/is modified)
When the client has a cached document, it can be conditional by providing an If-Modified-Since header to indicate that the client only wants the document to be modified after the specified date. ask. 304 (SC_NOT_MODIFIED) means that the cached version has been updated and the client should refresh the document. Additionally, the server will return the requested document with status code 200. Servlets generally do not set this status code directly. They would implement the getLastModified method and have the default service method handle conditional requests based on the modification date. The routine of this method has been given in Section 2.8 (An Example Using Servlet Initialization and Page Modification Dates/ an example of using servlet initialization and page modification date).
305 (Use Proxy/use proxy)
305 (SC_USE_PROXY) indicates that the requested document is to be obtained through the proxy server in the location header information. This status code is new in HTTP 1.1.
307 (Temporary Redirect/Temporary Redirect)
The browser's rules for handling the 307 status are the same as for the 302 status. The 307 status was added to HTTP 1.1 because many browsers performed the wrong redirect when receiving a 302 response even though the original message was a POST. It is only assumed that the browser will redirect on a POST request if it receives a 303 response. The purpose of adding this new status code is very clear: when the response is 303, follow the GET and POST requests; and when the 307 response, follow the GET request instead of the POST request. NOTE: For some reason there is no constant corresponding to this state in HttpServletResponse yet. This status code is new to HTTP 1.1.
Notice
There is no SC_TEMPORARY_REDIRECT constant in HttpServletResponse , so you can only use 307 status code explicitly.
400 (Bad Request/bad request)
400 (SC_BAD_REQUEST) indicates a syntax error in the client request.
401 (Unauthorized/Unauthorized)
401 (SC_UNAUTHORIZED) indicates that the client accessed a password-protected page without valid identity information in the authorization header. This response MUST contain a WWW-Authenticate authorization header. For example, "Restricting Access to Web Pages./Restricting Access to Web Pages." in Section 4.5 of this book.
403 (Forbidden)
403 (SC_FORBIDDEN) means that the server refuses to provide the requested resource unless authorized. This state is often caused by corrupt file or directory permissions on the server.
404 (Not Found/Not found)
The 404 (SC_NOT_FOUND) status may have been encountered by every network programmer. He tells the client that no resource can be found at the given address. It's the standard way of saying "no page visited". This status code is a common response and there is a dedicated method in the HttpServletResponse class to implement it: sendError("message"). The advantage of using sendError over setStatus is that the server will automatically generate an error page to display the error message. However, the Internet Explorer 5 browser ignores the error page you play by default and displays its custom error page, although Microsoft violates the HTTP specification by doing so. To turn off this feature, in the Tools menu, select Internet Options, go to the Advanced tab, and make sure the "Show friendly HTTP error messages" option (the 8th last option in my browser) is not selected. But few users know this option, so this feature is hidden by IE5 so that users cannot see the information you return to the user. However, other mainstream browsers and IE4 completely display the error prompt page generated by the server. You can refer to the examples in Figure 6-3 and 6-4.
core warning
By default, IE5 ignores error pages generated by the server.
405 (Method Not Allowed/method not allowed)
405 (SC_METHOD_NOT_ALLOWED) indicates that the request method (GET, POST, HEAD, PUT, DELETE, etc.) is not allowed for certain resources. This status code is new in HTTP 1.1.
406 (Not Acceptable/Unavailable)
406 (SC_NOT_ACCEPTABLE) indicates that the MIME type of the requested resource is inconsistent with the type specified in the Accept header information on the client. See the introduction of MIME types in Table 7.1 (HTTP 1.1 Response Headers and Their Meaning/HTTP 1.1 Response Headers and their meanings) in Section 7.2 of this book. 406 is new in HTTP 1.1.
407 (Proxy Authentication Required/proxy server authentication requirement)
407 (SC_PROXY_AUTHENTICATION_REQUIRED) is somewhat similar to the 401 status, except this status is for proxy servers. This status indicates that the client must be authenticated by the proxy server. The proxy server returns a Proxy-Authenticate response header to the client, which causes the client to reconnect using the Proxy-Authorization request header. This status code is new in HTTP 1.1.
408 (Request Timeout/request timeout)
408 (SC_REQUEST_TIMEOUT) means that the server waits too long for the client to send a request. This status code is new in HTTP 1.1.
409 (Conflict/Conflict)
This status is usually used with PUT requests, and the 409 (SC_CONFLICT) status is often used when trying to upload a file with an incorrect version. This status code is new in HTTP 1.1.
410 (Gone/no longer exists)
410 (SC_GONE) tells the client that the requested document no longer exists and there is no updated address. The 410 status is different from the 404, which is used when the guidance document has been removed, while the 404 is used for unknown reasons. This status code is new in HTTP 1.1.
411 (Length Required/requires data length)
411 (SC_LENGTH_REQUIRED) indicates that the server cannot process the request (assuming a POST request with attachments), unless the client sends a Content-Length header indicating the size of the data sent to the server. This status is new to HTTP 1.1.
412 (Precondition Failed/precondition error)
The 412 (SC_PRECONDITION_FAILED) status indicates that some prerequisites in the request header information are wrong. This status is new to HTTP 1.1.
413 (Request Entity Too Large/request entity is too large)
413 (SC_REQUEST_ENTITY_TOO_LARGE) tells the client that the requested document is larger than the server currently wants to handle. If the server thinks it can be processed after a while, it will include a Retry-After response header. This status is new to HTTP 1.1.
414 (Request URI Too Long/Request URI is too long)
The 414 (SC_REQUEST_URI_TOO_LONG) status is used when the URI is too long. The "URI" referred to here refers to the content after the host, domain name and port number in the URL. For example: In the URL--http://www.y2k-disaster.com:8080/we/look/silly/now/, the URI refers to /we/look/silly/now/. This status is new to HTTP 1.1.
415 (Unsupported Media Type/unsupported media format)
415 (SC_UNSUPPORTED_MEDIA_TYPE) means that the format type of the attachment attached to the request the server does not know how to handle. This status is new to HTTP 1.1.
416 (Requested Range Not Satisfiable/The request range cannot be satisfied)
416 indicates that the client includes a request for Range header information that the server cannot satisfy. This status is new to HTTP 1.1. The strange thing is that there is no corresponding constant in the HttpServletResponse of the servlet 2.1 API to represent this state.
Notice
In the servlet 2.1 specification, the class HttpServletResponse does not have a constant like SC_REQUESTED_RANGE_NOT_SATISFIABLE, so you can only use 416 directly. This constant is included in servlet 2.2 and later.
417 (Expectation Failed/Expectation Failed)
If the server gets an Expect request header with a value of 100-continue, it means that the client is asking if it can send an attachment in a subsequent request. In this case, the server will also use this status (417) to tell the browser server not to accept the attachment or use the 100 (SC_CONTINUE) status to tell the client that the attachment can continue to be sent. This status is new to HTTP 1.1.
500 (Internal Server Error/Internal Server Error)
500 (SC_INTERNAL_SERVER_ERROR) is the usual "server error" status. This state is often caused by CGI programs and possibly (hopefully not!) by servlets that do not function properly or return malformed headers.
501 (Not Implemented/Not Implemented)
The 501 (SC_NOT_IMPLEMENTED) status tells the client that the server does not support the functionality requested in the request. For example, the client executes a command such as PUT that the server does not support.
502 (Bad Gateway/Wrong Gateway)
502 (SC_BAD_GATEWAY) is used for servers acting as a proxy or gateway; this status indicates that the receiving server received an error response from the remote server.
503 (Service Unavailable/Service Unavailable)
Status code 503 (SC_SERVICE_UNAVAILABLE) indicates that the server cannot respond because it is under maintenance or has been overloaded. For example, the servlet returns this header if some thread or database connection pool is not free. The server can provide a Retry-After header to tell the client when it can try again.
504 (Gateway Timeout/Gateway Timeout)
This status is also used by servers acting as proxies or gateways; it indicates that the receiving server did not get a timely response from the remote server. This status is new to HTTP 1.1.
505 (HTTP Version Not Supported/Unsupported HTTP version)
The 505 (SC_HTTP_VERSION_NOT_SUPPORTED) status code means that the server does not support the HTTP version indicated in the request. This status is new to HTTP 1.1.