Excel/Word でリンクをクリックすると、ユーザー エージェントがサポートされているかどうかを調べるサイトにリンクすると、実際には別のものを使用しているのに、ユーザー エージェントが MSIE 7.0 を使用していると誤って想定される場合があります。 、クロムと言います。
リクエストとともに送信されたユーザー エージェントを調べると、リクエストが MSIE 7.0 からのものであることがわかります。ユーザーの観点からすると、MSIE 7.0 が使用されていないことは明らかです。
ここで何が起こっているのですか？ユーザーに間違ったメッセージを表示しないようにするにはどうすればよいですか?
問題は、リンクがクリックされたときに Excel/Word がリンクをプリロードしようとすることにあるようです。正常に読み込まれると、指定されたリンクでデフォルトのブラウザーが開きます。ただし、リンクのプリロード時に 302 リダイレクトにも従います。サイトが MSIE7 (現在では一般的になりつつある) をサポートしていない場合、ほとんどの場合、情報/エラー ページにリダイレクトされます。プリロード ルーチンは、元のリンクではなくブラウザでこのページを開くため、MSIE 7.0 がサポートされていない理由を説明するメッセージが表示されますが、ページが Chrome を使用してロードされたことを明確に確認できるユーザーは混乱します。
これを回避するための推奨されるコーディング方法はありますか?
これが以前に回答されている場合は、お知らせください。誰かの役に立てば幸いです。
これに対する最も簡単な解決策は、「IE 7 はサポートされていないページ」にブラウザー チェックを配置することです。Office プログラムは、(送信した間違ったユーザー エージェント文字列に基づいて) リダイレクトをたどり、エラー ページを読み込み、HTTP 200 応答を受け取り、リンクを既定のブラウザーにスローします。ブラウザは、適切なユーザー エージェント文字列を使用して、ページ自体を要求します。
そのため、ブラウザーがページを要求したら、ユーザー エージェント文字列を使用して、「サポートされていない」ページを本当に送り返すか、要求を実際のコンテンツにリダイレクトするかを確認できます。
ただし、これにより、リダイレクトされた元の URL を見つけるという問題が発生します。最初にページを要求する Office プロセスと、最終的にエンド ポイント URL が渡されるブラウザーとの間でセッションを共有すると、問題が発生します。ここでの回避策は、「サポートされていません」ページへのリダイレクト応答にクエリ文字列パラメーターとして元の要求 URL を含めることです。