Java ME 應用中的 HTTP 重導向處理最佳實踐

HTTP 1.1 規範允許伺服器以 302 狀態碼指示資源暫時移動，新位置放在 Location 標頭中。桌面瀏覽器會自動追蹤重導向，但 Java ME 裝置間的實作差異極大，若處理不當易導致應用程式異常終止。

常見陷阱

直接讀取 Location 標頭並重新連線的寫法在部份裝置會失效：

Connection c = (HttpConnection) Connector.open(uri);
int status = c.getResponseCode();
String new_uri = c.getHeaderField("Location"); // 部分裝置回傳 null
if (status == 302) {
    c.close();
    c = (HttpConnection) Connector.open(new_uri); // 此處拋出例外
}

根本原因分析

• 某些裝置的網路堆疊會內部處理 302，應用層只看到最終的 200 回應。
• 部分裝置無法正確解析 Location 標頭，導致該欄位為 null。
• 重導向資訊有時藏在回應本文（Body）中，而非標頭。

健壯的重導向處理演算法

採用「解析標頭 → 解析本文 → 等待狀態碼轉換」三階段策略：

Connection c = (HttpConnection) Connector.open(uri);
int status = c.getResponseCode();
String redirection = c.getHeaderField("Location");

if (status == HttpConnection.HTTP_TEMP_REDIRECT) { // 302
    if (redirection != null) {
        // 標準行為：關閉舊連線，開啟新 URI
    } else {
        // 1. 嘗試從回應本文解析 Location
        // parseResponseBodyForLocation(...)
        if (redirection != null) {
            // 找到則回標準流程
        } else {
            // 2. 輪詢等待狀態碼變為 200（最長 1 秒）
            long begin = System.currentTimeMillis();
            while (System.currentTimeMillis() - begin < 1000) {
                Thread.sleep(100);
                status = c.getResponseCode();
                if (status == 200) break;
            }
            if (status == 200) {
                // 視為成功，繼續處理
            } else {
                // 真正失敗，拋出例外
                throw new IOException("Redirect failed");
            }
        }
    }
}
// 處理 200 成功回應

關鍵設計原則

1. 容錯優先：不假設所有裝置行為一致，提供多層次備援。
2. 超時保護：輪詢設定上限（如 1 秒），避免無限等待阻塞 UI 執行緒。
3. 標準常數：使用 HttpConnection.HTTP_TEMP_REDIRECT 而非硬編碼 302。

參考 RFC 2616 (https://www.ietf.org/rfc/rfc2616.txt) 可深入理解 HTTP 重導向語意。此模式源自 Sun 技術文件整理，實測可相容主流 Java ME 裝置。