2

全て

これはまれに発生する問題です。実際、私はそれを再現するのに多くの時間を費やさなければなりませんでしたが、とにかくここにあります.

サーバーからデータを取得するために ASIHTTPRequest を使用しています。responseStatusCode == 200 以外のエラーをスローします。私のサーバーはいくつかのメッセージを返します。

私が気付いたのは、ワイヤレス接続 (ラップトップ シミュレーターの使用時) によっては、認証が必要な場合、ASIHttpRequest が 200 の応答を返すことがありますが、responseData はサーバーからのメッセージではなく、次のようなものです。

<HTML><HEAD><TITLE>Cisco Systems Inc. Web Authentication Redirect</TITLE><META http-equiv="Cache-control" content="no-cache"><META http-equiv="Pragma" content="no-cache"><META http-equiv="Expires" content="-1"><META http-equiv="refresh" content="1; URL=https://webauth-redirect.oracle.com/login.html?redirect=17.22.111.222/scripts_dummy/messagesx.php"></HEAD></HTML>

これは正しいです？サーバーからのメッセージが受信されなかった場合、responseStatusCode が 200 以外であってはなりません。

このような状況に対処するにはどうすればよいですか？responseStatusCode == 200 を確認した後の意味では十分ではないようです。これはほんの一例です。他のワイヤレス地域では、別のガベージが出力されます。

更新 これが果たす役割があるかどうかはわかりませんが、私は持っています

request.shouldUseRFC2616RedirectBehaviour = YES; // where request is ASIHTTPRequest
4

3 に答える 3

3

それはそうではないASIHTTPRequestか、クライアントコードのせいです。これは、クライアントが Web ブラウザーであることを期待し、HTTP 30xではなく、メタ リフレッシュ リダイレクト (つまり、リダイレクトが埋め込まれた HTML ページ) を送信するサーバーASIHTTPです。

これは、メタ リフレッシュがどのように悪用されたかを示す好例です。これは現在のページをリフレッシュすることを目的としていましたが、HTTP 30x がすでに設計されていたクライアントを別の場所に送信するためにメタ リフレッシュを使用し始めました。「メタ リフレッシュ vs 301 リダイレクト」をグーグルで検索すると、議論を行うブログ投稿がたくさん得られます。

あなたの場合、サーバーをブラウザ以外のクライアントに対してよりフレンドリーに動作させることができない限り、応答コードが 200 のときにこの状態を自分で確認し、リダイレクトを解析して、自分で要求を再発行する必要があります。

于 2012-05-06T00:26:55.133 に答える
1

これについてしばらく考えた後、別の戦略を思いつきました。コンテンツ タイプは保持され、混同されるべきではありません。

プロキシが挿入されたページを受信して​​いることを示すフラグとして、コンテンツ タイプを使用できるはずです。コンテンツ タイプ パラメーターを設定し、アプリ キーをそのパラメーターから外します。パラメータを持たない応答は無効です。

$content_type = 'text/html; FooCorp-MyApp=true'

ところで: HTML 処理を適切にサポートしていないのに、なぜ text/html のコンテンツ タイプを使用しているのですか。メタ リフレッシュは、HTML エンジンの一部である必要があります。HTML が必要ない場合は、XML、YAML、JSON などのデータ固有のコンテンツ タイプの使用を検討してください。

「それは有効ですか？」という疑問が提起されました。

RFC 2616 より: 3.7 メディアタイプ

タイプ、サブタイプ、およびパラメーターの属性名は、大文字と小文字が区別されません。パラメータ名のセマンティクスに応じて、パラメータ値の大文字と小文字が区別される場合とされない場合があります。線形空白 (LWS) は、タイプとサブタイプの間、または属性とその値の間で使用してはなりません。パラメータの有無は、メディア タイプ レジストリ内の定義に応じて、メディア タイプの処理にとって重要な場合があります。

一部の古い HTTP アプリケーションは、メディア タイプ パラメータを認識しないことに注意してください。データを古い HTTP アプリケーションに送信する場合、実装では、そのタイプ/サブタイプの定義で必要な場合にのみ、メディア タイプ パラメータを使用する必要があります (SHOULD)。

私にとっての教訓は、非標準のパラメーターを古いクライアントに送信しないことです。コンテキストでは、2000 年以降に作成されたクライアントに送信する場合、安全であることを意味します。

于 2012-05-16T13:18:30.917 に答える
0

最終的に、応答ヘッダーに特別なキーと値のペアを渡して、応答が中間リダイレクトからではなく、サーバーからのものであることをクライアントが理解できるようにしました。

function sendResponse($status = 200, $body = '', $content_type = 'text/html')
{
   $status_header = 'HTTP/1.1 ' . $status . ' ' . getStatusCodeMessage($status);
   header($status_header);
   header('Content-type: ' . $content_type);
   $value = 'success';
   header('myApp:' . $value); // --> I will always check in my client that the key myApp has the value success

echo $body;
}
于 2012-05-12T02:11:55.610 に答える