Post Submission Form redirection to Cross-domain Web site issue in servlet request

1. Description of the problem

After the HttpServlet request is received and logically processed, it is redirected to another web system across the domain, and the form data is submitted as a post.

2. Problem solving

This problem mainly addresses redirection, calling the HttpServletResponse object's Sendredirect () method, which is actually doing the following two things:

1. Set the status in the HTTP response header to 302;
2. Set the location value in the HTTP response header to the specified URL;

Described in the form of code, as follows:

Response.setstatus (302); 
Response.setheader ("Location", "Redirect_url");  

StatusCode 302 is the standard of HTTP1.0, formerly known as moved temporarily, now called found. Now using only for compatibility processing, the default location redirect for Response.sendredirect () is 302.
But HTTP 1.1 has 303 and 307 as a detailed supplement, which is actually a refinement of 302
303: For a POST request, it indicates that the request has been processed and the client can then use the Get method to request the URI in the location.
307: For post requests, the request has not been processed, and the client should location the post request to the URI in the.


Obviously you should now use StatusCode 307 because you want to resubmit the requested form to a new Cross-domain web system.
Resolution Code:
Response.setstatus (307);
Response.setheader ("Location", "Redirect_url");


3. Supplement (Excerpt from: http://www.cnblogs.com/helife/archive/2010/12/20/1911080.html)
The complete HTTP 1.1 specification is from RFC 2616, which you can check online at http://www.rfc-editor.org/. The status code for HTTP 1.1 is marked as a new feature because many browsers support only HTTP 1.0. You should only send a status code to a client that supports HTTP 1.1, and the support protocol version can be checked by calling Request.getrequestprotocol.
The remainder of this section describes the status codes in HTTP 1.1 in detail. These status codes are grouped into five main categories:




100-199 is used to specify certain actions that the client should correspond to.
200-299 is used to indicate that the request was successful.
300-399 is used for files that have been moved and is often included in locating header information to specify new address information.
400-499 is used to indicate a client error.
500-599 is used to support server errors.




The constants in httpservletresponse represent the status codes associated with different standard messages. In the servlet program, you will use the identity of these constants more than the status code. For example: You will generally use Response.setstatus (response). sc_no_content) instead of Response.setstatus (204) because the latter is not easy to understand and leads to errors. However, you should note that the server allows a slight change to the message, while the client only notices the numeric value of the status code. So the server may only return http/1.1 200 instead of http/1.1 OK.
continue/(continued)
If the server receives a 100-continue request in the header message, this means that the client asks if the attachment can be sent on subsequent requests. In this case, the server uses Sc_continue to allow the client to continue or use 417 (expectation Failed) to tell the client that it does not agree to accept the attachment. This status code is newly added in HTTP 1.1.
(Switching protocols/Conversion Protocol)
The Sc_switching_protocols status code means that the server will change to a different protocol according to the header information on it. This is a new addition in HTTP 1.1.
(ok/Normal)
(SC_OK) means everything is OK. Typically used for corresponding get and post requests. This status code is default to the servlet, and 200 is obtained if the SetStatus method is not invoked.
201 (created/created)
201 (sc_created) indicates that the server created a new document in the requested response, and that its URL should be given in the locator header information.
accepted/(accepted)
Sc_accepted tells the client that the request is being executed, but has not finished processing it.
203 (non-authoritative information/unofficial information)
The Status Code 203 (sc_non_authoritative_information) indicates that the document is returned normally, but some response header information may be incorrect because a copy of the document is in use. This is a new addition 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. This status code is useful for users to overload a page periodically, and you can determine if 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 method works on pages that are automatically overloaded by refreshing the response header information or equivalent HTML tags, because it returns a 204 status code stop after the overload. However, automatic overloading based on JavaScript scripts still needs to work in this case. A detailed discussion of the 7.2 (HTTP 1.1 Response Headers and their 1.1 response header information and their meaning) can be read in this book.
205 (reset content/reset content)
Resetting content 205 (sc_reset_content) means that the browser will reset the document display, although there are no new documents. This status code is used to force the browser to clear the form field. This is a new addition in HTTP 1.1.
206 (Partial content/local content)
206 (sc_partial_content) is sent when the server completes a local request that contains the range header information. This is a new addition in HTTP 1.1.
(multiple choices/multiple selection)
Sc_multiple_choices indicates that the requested document can be found in more than one place and will be listed in the returned document. If the server has preference settings, the preferences are listed in the location response header information.
Permanently (moved)
The sc_moved_permanently state refers to the requested document elsewhere, and the new URL of the document is given in the positional response header information. The browser automatically connects to the new URL.
302 (found/found)
Similar to 301, only the URL given in the locator header information should be interpreted as a temporary exchange address rather than permanent. Note: In HTTP 1.0, messages are temporarily moved (moved temporarily) instead of being found, so the constants in HttpServletResponse are sc_moved_temporarily not the sc_found we think.
Attention
Constants representing the status code 302 are sc_moved_temporarily rather than sc_found.
Status Code 302 is useful because the browser automatically connects to the new URL given in the response header information. This is very useful, and there is a special method for this--sendredirect. Use Response.sendredirect (URL) than call Response.setstatus (response. sc_moved_temporarily) and Response.setheader ("Location", url) a few more benefits. First, the Response.sendredirect (URL) method is obviously simple and easy. Second, the servlet automatically builds a page to save the connection for the display of browsers that are not automatically diverted. Finally, in the servlet 2.2 version (version in Java), Sendredirect is able to handle relative paths and automatically convert to absolute paths. But you can only use absolute paths in version 2.1.
If you move the user to another page of the site, you will use the Encodeurl method in HttpServletResponse to route the URL. Doing so prevents the constant use of session tracking based on URL overrides. URL rewriting is a way to keep track of users who do not use cookies on your site. This is done by attaching path information at the end of each URL, but the servlet session tracking API automatically notices these details. Session tracking is discussed in chapter Nineth, and the habit of using encodeurl makes it much easier to add session tracking later.
Core Skills
If you move a user to another page of your site, it is better to plan your session tracking (sessions tracking) in a response.sendredirect (Response.encodeurl) way than just call Response.sendredirect (URL) is much better.
This status code can sometimes be used with 301 exchange. For example, if you mistakenly access the Http://host/~user (the path information is incomplete), some servers reply to the 301 status code and some reply 302. Technically, if the initial request is a get browser is simply assumed to automatically turn. For more details, see the discussion of status code 307.
303 (see other/for additional information)
This status code is similar to 301 or 302, except that if the initial request is POST, then the new document (given in the locator header information) is retrieved from the medicinal get. This status code is newly added to HTTP 1.1.
304 (not modified/for correction)
When a client has a cached document, it is possible to make conditional requests by providing a if-modified-since header to indicate that the client only wants the document to be modified after a specified date. 304 (sc_not_modified) means that the buffered version has been updated and the client should refresh the document. In addition, the server will return the requested document and status Code 200. The servlet typically does not set this status code directly. They implement the Getlastmodified method and let the default service method handle conditional requests based on the fixed date. The routine of this method has been given in part 2.8 (an Example using servlet initialization and page modification dates/A example using servlet initialization and page modification dates).
305 (use proxy/proxy)
305 (Sc_use_proxy) indicates that the requested document is obtained through a proxy server in the locator header information. This status code is newly added to HTTP 1.1.
307 (Temporary redirect/temporary redirection)
The browser handles 307 states in the same rule as 302. The 307 status is added to HTTP 1.1 because many browsers still perform the wrong turn when they receive a 302 response, even if the original message is post. It is only assumed that the browser will be redirected on post requests when a 303 response is received. The purpose of adding this new status code is clear: To turn on a get and post request when the response is 303, and to turn on a GET request instead of a POST request when the 307 response is made. Note: For some reason there are no constants corresponding to this state in HttpServletResponse. The status code is newly added to HTTP 1.1.
Attention
There are no Sc_temporary_redirect constants in HttpServletResponse, so you can only display the use of 307 status codes.
(Bad request/wrong request)
Sc_bad_request indicates a syntax error in the client request.
401 (unauthorized/not authorized)
401 (sc_unauthorized) indicates that the client accesses a password-protected page when there is no valid identity information in the authorization header information. This response must contain a Www-authenticate authorization header. For example, the restricting access to Web pages./restricts access to Web pages in part 4.5 of this book. ”
403 (forbidden/Forbidden)
403 (Sc_forbidden) means that the server refuses to provide the requested resource unless authorized otherwise. This state is often caused by corrupted files or directory permissions on the server.
404 (not found/found)
404 (Sc_not_found) state each network programmer may have encountered, he told the client that the address given could not find any resources. It is the standard way to represent "pages without access." This status code is a commonly used response and there is a special way to implement it in the HttpServletResponse class: Senderror ("message"). The advantage of using senderror relative to SetStatus is that the server automatically generates an error page to display the error message. However, the Internet Explorer 5 browser defaults to ignoring the error page you are playing and displaying its custom error page, although Microsoft violates the HTTP specification. To turn off this feature, in the Tools menu, select Internet Options, go to the Advanced tab, and confirm that the "Show friendly HTTP error message" option (the 8th in my browser) is not selected. But few users know about this option, so this feature is hidden by IE5 and users cannot see the information you return to the user. Other mainstream browsers and IE4 all display the server-generated error prompt page. You can refer to the examples in figures 6-3 and 6-4.
Core warning
By default, IE5 ignores server-generated error-prompt pages.
405 (Method not allowed/is not allowed)
405 (sc_method_not_allowed) indicates that the request method (get, POST, head, put, DELETE, and so on) is not allowed for specific resources. The status code is newly added to HTTP 1.1.
406 (not acceptable/inaccessible)
406 (sc_not_acceptable) indicates that the MIME type of the request resource is inconsistent with the type specified in the Accept header information in the client. See the description of the MIME type in Table 7.1 (HTTP 1.1 Response Headers and their Meaning/http 1.1 response header information and their meaning) in part 7.2 of this book. 406 is newly added to HTTP 1.1.
407 (proxy authentication required/Agent Server authentication requirements)
407 (sc_proxy_authentication_required) is somewhat similar to the 401 state, except that this state is used for proxy servers. This state indicates that the client must pass the authentication of the proxy server. The proxy server returns a proxy-authenticate response header message to the client, which causes the client to reconnect with the header information with the proxy-authorization request. The status code is newly added to HTTP 1.1.
408 (Request timeout/Timeout)
408 (sc_request_timeout) means that the service side waits too long for the client to send a request. The status code is newly added to HTTP 1.1.
409 (conflict/conflict)
This state is usually used in conjunction with put requests, and 409 (sc_conflict) states are often used when attempting to upload files with incorrect versions. The status code is newly added to HTTP 1.1.
410 (gone/no longer exists)
410 (Sc_gone) tells the client that the requested document no longer exists and does not have an updated address. The 410 status differs from 404,410 when the instruction document has been moved, and 404 is not accessible for unknown reasons. The status code is newly added to HTTP 1.1.
411 (length required/requires data lengths)
411 (sc_length_required) indicates that the server cannot process the request (assumed to be a POST request with an attachment) unless the client sends Content-length header information indicating the size of the data sent to the server. This state is newly added to HTTP 1.1.
412 (precondition failed/prerequisite error)
The 412 (sc_precondition_failed) state indicates that some of the prerequisites in the request header information are incorrect. This state is newly added to HTTP 1.1.
413 (Request Entity Too large/requested entity too large)
413 (Sc_request_entity_too_large) tells the client that the requested document is now larger than the server now wants to handle. If the server thinks it can handle it over a period of time, it will include a retry-after response header information. This state is newly added to HTTP 1.1.
414 (Request URI Too long/requested URI is too long)
The 414 (Sc_request_uri_too_long) state is used when the URI is too long. The "URI" referred to here refers to the contents of the host, domain name, and port number in the URL. For example: In url--http://www.y2k-disaster.com:8080/we/look/silly/now/the URI refers to the/we/look/silly/now/. This state is newly added to HTTP 1.1.
415 (media type/not supported by unsupported)
415 (Sc_unsupported_media_type) means that the format type server for the attached attachment to the request does not know what to do with it. This state is newly added to HTTP 1.1.
416 (requested range not satisfiable/request scope not satisfied)
416 indicates that the client contains a request for range header information that the server cannot meet. This state is newly added to HTTP 1.1. Oddly, there is no corresponding constant in the httpservletresponse of the Servlet 2.1 version API that represents the state.
Attention
In the specification of the servlet 2.1, class HttpServletResponse does not have sc_requested_range_not_satisfiable such constants, so you can only use 416 directly. This constant is included after the servlet version 2.2.
417 (expectation failed/expected failure)
If the server gets a expect request header information with a 100-continue value, this means that the client is asking if the attachment can be sent in a subsequent request. In this case, the server will also use this state (417) to tell the browser server not to receive the attachment or Sc_continue status to tell the client to continue sending the attachment. This state is newly added to HTTP 1.1.
(Internal server error/Internal server error)
(Sc_internal_server_error) is a commonly used "server error" state. This state is often caused by CGI programs and may be (hopefully not). is caused by a servlet that does not function correctly or returns the wrong header information.
501 (not implemented/not implemented)
The 501 (sc_not_implemented) status tells the client server that the feature requested in the request is not supported. For example, a client performs a command that is not supported by a server such as put.
502 (Bad gateway/wrong gateway)
502 (Sc_bad_gateway) is used to serve as a proxy or gateway server, which indicates that the receiving server received an error response from the remote server.
503 (Service unavailable/services not available)
The Status Code 503 (sc_service_unavailable) indicates that the server is unable to respond due to maintenance or overloading. For example, if some threads or database connection pools are no longer idle, the servlet returns this header information. The server can provide a Retry-after header message telling the client when it can be tried again.
504 (Gateway timeout/gateways Timeout)
This state is also used to serve as a proxy or gateway server, and it indicates that the receiving server did not receive a timely response from the remote server. This state is newly added to HTTP 1.1.
505 (HTTP version not supported/unsupported versions of HTTP)
The 505 (sc_http_version_not_supported) status code is that the server does not support the HTTP version indicated in the request. This state is newly added to HTTP 1.1.