WebSurfer's Home

トップ > Blog 1   |   ログイン
APMLフィルター

IE11 と Referer

by WebSurfer 2017年8月13日 17:02

ASP.NET 4 の Web Forms アプリで、クエリ文字列に日本語を含めて要求をかけた場合、Windows 10 の IE11 と Edge ではポストバックの際 Referer が送信されないという話を書きます。(ASP.NET 4.5 では問題は解消されています。ASP.NET 3.5 以下は未確認です)

Fiddler によるキャプチャ

そもそもの原因は Windows 10 の IE11 や Edge ではなく、ASP.NET 4(3.5 以前も?・・・未確認です)が応答の from 要素に設定する action 属性にあるようです。

例えば、IE11 のアドレスバーに直接以下の URL(クエリ文字列は "日本語" を UTF-8 のパーセントエンコードしたものです)を入力して直接ページを GET 要求したとします。

http://aspnet4site/test.aspx?P1=%e6%97%a5%e6%9c%ac%e8%aa%9e

そうすると、ASP.NET により応答の form 要素の action 属性に設定される URL は以下のようになります。

action="./test.aspx?P1=%u65e5%u672c%u8a9e"

つまり、要求 URL のクエリ文字列の "日本語" は UTF-8 のパーセントエンコーディングなのに、応答の form 要素の action 属性に設定されるのは Unicode のパーセントエンコーディングになってしまいます。そこに問題があるようです。

具体的には下にアップした簡単なサンプルのページ test.aspx で再現できます。

上の画像は、UTF-8 でパーセントエンコーディングした "日本語" をクエリ文字列に含めた URL を IE11 のアドレスバーに直接入力して test.aspx を要求し、表示されたページで 2 回ポストバックを行ったときの Fiddler によるキャプチャ画像です。

上の画像の #1 が初回の要求・応答で、#3 が 1 回目のポストバック、#4 が 2 回目のポストバックの際の要求・応答です。

問題は 2 回目のポストバックのときで、ブラウザからリファラが送信されません。Edge も同様で 2 回目のポストバックの際はリファラは送信されません。

どのような動きになるかと言うと・・・

#1 の初回要求に対して ASP.NET が返す応答の form 要素の action 属性に同じページの URL が設定されますが、URL に含まれるクエリ文字列の "日本語" は Unicode のパーセントエンコーディング %u65e5%u672c%u8a9e となってしまいます。

なので、1 回目のポストバックの時は要求 URL に含まれるクエリ文字列は %u65e5%u672c%u8a9e となります。上の画像の #3 を見てください。

ただし、1 回目のポストバックの際にブラウザから送信されるリファラは、最初の要求の URL(すなわちアドレスバーに直接入力した URL)になります。つまり、クエリ文字列の "日本語は" UTF-8 のパーセントエンコーディングなので問題なくリファラとして送信されます。問題は 2 回目以降です。

2 回目のポストバックの時(上の画像の #4)は、1 回目のポストバックの際の要求 URL(すなわちクエリ文字列の "日本語" が %u65e5%u672c%u8a9e)をリファラとして送信するはずですが、Windows 10 の IE11 と Edge では送信されません。3 回目、4 回目も同様です。

Microsoft の公式文書が見つけられないので想像ですが、Windows 10 の IE11 と Edge ではセキュリティ対策が強化され、URL に UTF-8 として解釈できないコードがあるとリファラを送信しないということではないかと思っています。

ちなみに、Windows 7 の IE11 では %u65e5%u672c%u8a9e となってしまっていてもリファラは送信されるそうです(聞いた話で未検証・未確認)。Chrome 60.0.3112.90, Firefox 54.0.1 では %u65e5%u672c%u8a9e でも送信されることは確認しました。

やはり、URL にはクエリ文字列を含めて ASCII 文字のみ使用することで徹底するのがよさそうです。

サンプルページ test.aspx

<%@ Page Language="C#" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script runat="server">
    protected void Page_Load(object sender, EventArgs e)
    {
        if (Request.UrlReferrer != null)
        {
            Label1.Text = Request.UrlReferrer.ToString();
        }
        else
        {
            Label1.Text = "無し";
        }
    }
</script>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
    <h1>Page B</h1>
    <asp:Button ID="Button1" runat="server" Text="Button" />
    <br />
    UrlReferrer: 
    <asp:Label ID="Label1" runat="server"></asp:Label>
    </form>
</body>
</html>

Tags: , ,

ASP.NET

IE11 で[戻る]ボタンが使えない

by WebSurfer 2016年8月24日 10:37

ユーザーが Power Users グループに属していると IE11 の[戻る]ボタンが使えない(グレーアウトされる)ことがあるという話を書きます。

Power Users グループ

元は MSDN Forum の「IE11で戻るボタンが使えない」という表題のスレッドでの話です。

そのスレッドを読めば話はすぐわかるのですが、備忘録として自分のブログの記事にも書いておくことにしました。

簡単に話の内容を書くと・・・

IE11 にアップグレードしたら一部のドメインユーザーで IE11 の[戻る]ボタンが使えなくなる(グレーアウトされる)という問題が発生。

ググって調べてみると、ユーザーを Power Users グループから外したら問題が解決したという記事を発見。(ただし原因は不明)

MSDN Forum の質問者さんの方でも、ユーザーを Power Users グループから外すことで問題が解消した。

・・・ということです。

ネットの情報だけで自分で検証したわけではないし、そもそも何故 Power Users グループが影響するのか不明というのがアレですが、IE11 の[戻る]ボタンが使えないという問題に遭遇したら Power Users グループに属していないか調べてみるのがよさそうです。

Tags: ,

その他

SQL Server Reporting Services と IE11

by WebSurfer 2016年2月10日 14:56

SQL Server Reporting Services (SSRS) のレポートを見るのに IE11 を使うと、表示が崩れるとか印刷ボタンが表示されないなどのトラブルが出るという話を MSDN フォーラムなどで時々聞きます。

その理由を書いた MSDN Blogs の記事を見つけたので忘れないようにその記事へのリンクを張っておきます。

IE 11 browser support for Reporting services versions prior to 2012

その記事によると SQL Server 2012 SP 1 CU 8 より前の Reporting Services は IE11 を検出できないのが原因だそうです。(User Agent が変わったから?)(Edge はまた話が違います。この記事の下の方の 2016/6/9 追記を見てください)

解決策はほとんどなくて、

  1. IE11 の互換表示設定を行う。(これは何の効果もないという話も聞きますが)
  2. バージョン 2012 SP 1 CU 8 以降にアップグレードする。

ぐらいだそうです。

ちなみに、SQL Server 2012 にも同じ問題があって、それは SP1 CU 8 以降のリリースで直したようです。詳しくは以下の Connect の記事を見てください。

SQL Server Reporting Services is not compatible with Internet Explorer 11

上記 Connect では「解決済み」になっていますが、それは SQL Server 2012 SP 1 CU 8 以降のバージョンの話で、それより前のバージョン例えば SQL Server 2008 R2 では直す気はなさそうです。

上記はググって調べただけで、実際に自分の環境で上記の不具合や解決策が有効かを確認したわけではありませんのでご注意ください。

-------- 2016/6/9 追記 --------

MSDN フォーラムの記事「【SSRS】Microsoft Edgeを利用した場合に、印刷ボタンが表示されない」で初めて知ったのですが、Edge は ActiveX をサポートしてないそうです。

なので、SQL Server のバージョンが 2012 SP 1 CU 8 以降でも印刷はできませんのでご注意ください。

-------- 2017/5/8 追記 --------

ようやく Windows 10 Pro. 64-bit のノート PC を買えたので、それに搭載されている IE11 でどのように表示されるかを調べてみました。IE9 と IE11 での比較の画像を貼っておきます。

アプリは、ReportViewer を使用してパラメーターを含む詳細 (RDLC) レポートを作成する (SSRS チュートリアル) に従って Visual Studio 2010 Professional で作ったものです。Microsoft.ReportViewer.WebForms のバージョンは 10 で、具体的に SQL Server のどのバージョンものかは不明ですが、少なくとも SQL Server 2012 SP 1 CU 8 より前のものであることは間違いないです。

そのアプリを Vista SP2 の IE9 で表示したのが以下の画像です。期待した通りの表示になり、印刷ボタンも表示されています。

IE9 で ReportViewer を表示

ところが、これを Windows 10 の IE11 で表示すると以下のようになってしまいます。

IE11 で ReportViewer を表示

確かにヘッダに印刷ボタンは表示されていません。他にも、サイズ設定のドロップダウンがヘッダに表示されませんし、ReportViewer の Hieght プロパティの設定(デフォルトで 400px)が無視されています。

ちなみに、F12 開発者ツールの[エミュレーション]タブで、以下の画像のように[ドキュメントモード]と[ユーザーエージェント文字列]の両方を IE9 にしてやると、IE9 と同様な表示になります(機能まで同じかは調べていません)。

F12 開発者ツール

自分の環境で試した限りですが、[ユーザーエージェント文字列]がヘッダの印刷ボタンとサイズ設定ドロップダウンに、[ドキュメントモード]が Hieght プロパティに影響しているようです。

Tags: ,

SQL Server

About this blog

2010年5月にこのブログを立ち上げました。その後 ブログ2 を追加し、ここは ASP.NET 関係のトピックス、ブログ2はそれ以外のトピックスに分けました。

Calendar

<<  2017年10月  >>
24252627282930
1234567
891011121314
15161718192021
22232425262728
2930311234

View posts in large calendar