J2ME 應用設計指南：優雅處理 HTTP 302 重定向

問題背景

HTTP 1.1 允許伺服器以 302 狀態碼指示資源暫時移動，新位置在 Location Header。桌面瀏覽器自動追蹤，但移動設備實作差異極大：有的底層協議棧自動處理、有的回傳 302 但 Location 為 null、有的將新 URL 放在回應本文中。

失敗的簡單寫法

HttpConnection c = (HttpConnection) Connector.open(uri);
int status = c.getResponseCode();
String newUri = c.getHeaderField("Location"); // 可能為 null
if (status == 302) {
    c.close();
    c = (HttpConnection) Connector.open(newUri); // 這裡會崩潰
}

健壯的重定向處理演算法

1. 取得狀態碼與 Location Header。
2. 若 302 且 Location 非 null → 關閉舊連線，開新連線至新 URI（標準行為）。
3. 若 Location 為 null → 解析回應本文尋找 "Location" 或 URL 模式。
4. 仍找不到 → 等待 10~1000 ms 輪詢狀態碼，直到變為 200（底層已自動完成重定向）。
5. 若超時仍非 200 → 拋出異常失敗。

參考實作代碼

HttpConnection hc = (HttpConnection) Connector.open(uri);
int status = hc.getResponseCode();
String redirect = hc.getHeaderField("Location");

if (status == HttpConnection.HTTP_TEMP_REDIRECT) {
    if (redirect != null) {
        // 標準行為：重新開啟新連線
        hc.close();
        hc = (HttpConnection) Connector.open(redirect);
    } else {
        // 嘗試解析回應本文
        redirect = parseContentForLocation(hc); // 自行實作
        if (redirect != null) {
            hc.close();
            hc = (HttpConnection) Connector.open(redirect);
        } else {
            long start = System.currentTimeMillis();
            while (System.currentTimeMillis() - start < 1000) {
                Thread.sleep(100);
                int newStatus = hc.getResponseCode();
                if (newStatus == 200) break; // 底層已完成重定向
            }
            if (hc.getResponseCode() != 200) {
                throw new IOException("Redirect failed");
            }
        }
    }
}
// 繼續處理 200 回應...

核心原則

• 不信任單一機制，多重備援。
• 輪詢間隔 100 ms，總超時 1 秒，平衡回應速度與電量。
• 最終以 HTTP 200 為成功標準。