[Design Guidelines - General Introduction]
[Design Guidelines - Technical Overview]
Contents
- Problem Description
- Solution Description
- List of Affected Devices
- Keywords
1. Problem Description
The HTTP 1.1 protocol allows a web server to temporary change the location of a resource (mark up, image, etc.) The link is not broken, the designated content has moved for a while. The server answers with a HTTP response code 302 and an alternate URI in the Location field. Under regular circumstances, the client browser shall move on to the temporary redirection URI. Check details in Additional Information (and HTTP protocol definition) section. Different behaviours are observed when devices are facing a 302 response code.
Here is the naïve version of the code handling the temporary redirection, it crashes on 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
}
|
Almost all application using HTTP networking should be prepared to handle 302 redirection as it is a standard mechanism of HTTP 1.1.
2. Solution Description
No special requirement, except careful debugging.
Dynamic adaptation to the device.
It turns out that on certain devices, the underlying network stack handles the redirection, the 302 code is used to notify the application about this internal processing, the application should wait as long as response code equals 302. Other device do not parse HTTP headers properly, the Location header field is set to null while the actual redirection location is inside in response content. A fragmentation aware developer should use the following approach:
- If something is provided in the response content, parse and lookup for a Location header, if successful, close the initial connection and move on to the redirection
- If nothing was found in the response content, wait at least 10 milliseconds and up to 1 second for the status code to change from 302 to 200, as soon as the code changes, proceed as if no error has happened.
None.
Example: This code fragment sketches a robust handling of 302 redirection, with buggy devices.
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 the standard HTTP 1.1 behaviour, 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 was found, fall back to the standard behaviour.
} else {
long begin_wait = System.currentTimeMillis();
while (System.currentTimeMillis() - begin_wait < 1000 || response != 200) {
sleep(100);
response = httpConnection.getResponseCode();
};
if (response == 200) {
// 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 an exception.
};
};
};
} else // Handle other error codes here
};
// Handle success here (status == 200)
|
Reference: HTTP 1.1 302 Redirection status code definition (from HTTP 1.1 standard).
The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.
The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
Note: RFC 1945 and RFC 2068 specify that the client is not allowed
to change the method on the redirected request. However, most
existing user agent implementations treat 302 as if it were a 303
response, performing a GET on the Location field-value regardless
of the original request method. The status codes 303 and 307 have
been added for servers that wish to make unambiguously clear which
kind of reaction is expected of the client.
|
Reference: MIDP 2 specification (JSR 118)
public static final int HTTP_MOVED_TEMP
302: The requested resource resides temporarily under a different URI. (Note: the name of this status code reflects the earlier publication of RFC2068, which was changed in RFC2616 from "moved temporalily" to "found". The semantics were not changed. The Location header indicates where the application should resend the request.)
|
3. List of Affected Devices
All devices
4. Keywords
Network, Multiple Connections, Browser, Email, IM, Network games, Mapping, Location, redirect, http 302
Copyright 2006 Sun Microsystems, Inc. and Orange SA All Rights Reserved.
|
|
Print-friendly Version
