Java Me application Design Guide Network redirection

The HTTP 1.1 protocol allows a Web server to temporarily change the location of a resource, which means that the resource you are accessing is at another address. The response code returned by the server is 302, and the new address is stored in the header, and the header name is location. Normally, the client browser should point to a temporary access address. However, the gap between mobile terminals is very large, in the processing of 302 return code, the behavior of the device varies greatly.

The following code can be used to handle redirection issues, but can cause an application error in some devices.

Connection c = (HttpConnection) Connector.open(uri);
int status = c.getResponseCode();
String new_uri = c.getHeaderField("Location"); // new_uri is null on some devices
if (status == 302) {
c.close();
c = (HttpConnection) Connector.open(new_uri); // Breaks here
}

Since redirection is an attribute of HTTP 1.1, all 1.1 compatible devices need to consider this issue. Here's how to solve this problem.

It turns out that on some devices, the underlying network protocol stack handles the problem of redirection, and the 302 response code tells the application's internal processing process. The application should wait until the response code equals 302. However, some devices do not correctly parse the Location field from the response, so that the contents of the Location field are null and the response code is stored in the content of the response. Experienced engineers will use the following solution.

1 Resolve the response, look for a new address in the location or response, and, if found, turn off the previous connection and move on to the new connection.

2 If nothing is found, then wait for 10-1000ms until the status code changes from 302 to 200. Handle the response immediately as if no error occurred.

The following code can be a good solution to the problem of redirection, for everyone to refer to and improve.

Connection C = (httpconnection) connector.open (URI);
int status = C.getresponsecode ();
String redirection = Httpconnection.getheaderfield ("Location");
if (status = = Httpconnection.http_temp_redirect) {
if (redirection!= null) {
//This standard HTTP 1.1 b Ehaviour, move on to the redirection URI (basically restarting again).
} else {
//Parse The content of the HTTP response, if any.
//Lookup for a "Location" header, if found, set value to the redirection variable
if (redirection!= null) {
//Since location is found, fall back to the Standar D behaviour.
} else {
Long begin_wait = System.currenttimemillis ();
while (System.currenttimemillis ()-begin_wait < 10 00 | | Response!= {
sleep (m);
Response = Httpconnection.getresponsecode ();
};
if (response =) {
//Once again we ' re back on tracks, continue processing as if no error has ever happen
else {
//Here we ' re really hopeless.Either the server did provided a valid redirection URI,
//or the device did not preserved it. The best option is probably to fail by throwing a exception.
};
};
};
} else//Handle Other error codes here
};
//Handle success here (status = =)

You can also look at the details of the HTTP protocol, Http://www.ietf.org/rfc/rfc2616.txt. This article is compiled by the author while reading Sun's technical articles. You can read the original through the address below, you are also welcome to compile other good articles to jointly promote the development of Java me technology in the country.