IE8 の User-Agent が長すぎる
- 2009/11/13(金) 12:30:22
これが引き起こす問題は何か？
VisualStudio 2005 で作成したものならば問題が無い模様。問題は VisualStudio 2003 で作成した物で発生している。
User-Agent の Parse に失敗して、 browser の特定や機能使用可否の確認ができず、結果 cookie が使えないという事が起きる模様。
限界値は 256 文字で、 User-Agent の閉じ括弧 ")" の後ろに空白が付いて 257 文字以上になっている場合には問題が無いが、閉じ括弧自体が 257 文字目以降になった場合には問題が発生する。この瞬間に Parse が失敗するのだが、ページの実行自体には問題が見受けられない。但しこれは要求者の browser の特定・機能確認に使用される HttpBrowserCapabilities object の内容が初期値になっている事から判明する。 Request.Browser で access できるこの object の各 parameter は unknown や false で埋められる。これを用いて条件分岐している code を書いていると、当然正常に動作しない。
一番の問題は、 ASP.NET の内部の挙動でこの値に依存して駆動する部分がある事だ。 cookie は使えないという。 cookie 付き redirect は support していないという。だからそれを行わせて貰えない。 code 側に幾らそれを記述しても、実際に処理をする所でスルーし、例外すら起こさない。 server 側 code は設定した、飛ばした気でいるにも関わらず。
2008 向けに convert する作業を試みるか。色々な事情から至極面倒臭い事にはなっているのだが。
削除できないフォルダ
- 2009/03/23(月) 21:53:45
Vista にて。
- エクスプローラでテスト用フォルダ作成。
- 適当に画像ファイルを置く。
- 違うフォルダを参照。
- 戻る。フォルダの体裁が「画像またはビデオ」になる。
- フォルダのカスタマイズで「全ての項目」にし、サブディレクトリにも適用。
- エクスプローラを閉じる。
- コマンドプロンプトでフォルダ内のファイルを削除。 ( del コマンド )
- コマンドプロンプトでフォルダを削除。 ( rmdir コマンド )
これでアクセス拒否。
当該フォルダにて dir /as を実行すると desktop.ini がある。よって del /as desktop.ini を実行。この状況で rmdir を実施しても、やはりアクセス拒否。
エクスプローラからは削除できる。問題はプログラムから削除できない事。
基本的にそんな作業はしないとも言えるが、もしそうなった場合に今提示している情報からは対処法が分からない。どうしたものだか。
現在情報探索中。
( 追記 )
結論 : SHFileOperation で消すべし。
- rmdir /s /q で実行すると消える。
- フォルダのカスタマイズをすると駄目。ファイルの有無は関係ない。
- プログラムから消す事を希望。現在は FindFirstFile で列挙して、ファイルを削除、フォルダは再帰呼び出しで削除を続ける。フォルダのカスタマイズをしなければ削除できる。
- FindFirstFile で desktop.ini は hit する。
- desktop.ini は DeleteFile で削除できる。よって RemoveDirectory をする時には空になっている筈。
- 再起動しても削除できない状態に変化はない。
IE8 対策
- 2008/12/11(木) 20:50:36
IE8 に向けて ActiveX control の提供側は何らかの対処をする必要がある場合がある。 VC 7.1 以前を用いて ATL を使用している場合には実行が抑制される可能性があるからだ。 これを確かめるには Vista + IE7 において適切な設定にした上で実際に止まるかどうか 見れば良い。
コンピュータ > プロパティ > システムの詳細設定 > 詳細設定 > パフォーマンス > 設定
データ実行防止
より保護される方に設定する。次に IE の設定。
IE7 を管理者権限で起動 > メニューのツールよりインターネットオプション > 詳細設定
セキュリティの「オンラインからの攻撃の緩和に役立てるため、メモリ保護を有効にする」にチェック。 このチェックの為に管理者権限が必要で、普通に起動すると表示の様に操作できない。
この環境 (*) で実際に自分の提供する ActiveX control を起動した際に「停止しました」という旨と 共に IE が強制終了するならば要対策。
(*) それ以外のセキュリティの設定は IE の標準状態に適切に設定されている事を前提とする。
基本的には VC 8.0 以降であれば良いとの事。 自分が困ったのは「如何にして VC 8.0 等の runtime library を提供するか」という事だった。 あまり困った人がいないのか、見つかったのはこちら。
How can I deploy Visual Studio 2008 C Run-time Library in cab file?
http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/65049937-d223-4b17-b186-29963c5c647c/
これを見ても少々悩んだので、手順をメモしておく。
- 開発環境と、対応する runtime installer を入手する。
今回使用したのは VC9.0 SP1 であり、これに対応する runtime library の installer を公式 site より ダウンロードしてきた。現時点ではこちらで vcredist_x86.exe が入手できる。
http://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=a5c84275-3b97-4ab7-a40d-3802b2af5fc2 - cabarc と signcode 、そして適切な証明書を準備する。
これは ActiveX control を web 向けに deploy しているなら保有している筈。
- vcredist_x86.exe を取り決めた名称の cab file に含める。
これは ActiveX control を含める cab file とは別に用意。ここでは vc9dll.cab としておく。 vc9dll.cab には inf file も要らない。ただ installer を固めるだけで良い。
- 上記で作成した cab file に署名する。
中身が公式のものだけなのに自前の署名をするのに違和感があるが、署名なきものは 蹴られてしまう。回避の為に必要。
- 提供する ActiveX control 側の inf file に適切な設定をする。
前述の英語サイトと違うのは ATL90.dll に依存している事を明記している事と SP1 を利用した事による version 指定の違い程度。 library の version は Windows folder 内 WinSxs の中から当該 dll 、例えば x86_microsoft.vc90.crt..... 辺りの中にある msvcp90.dll のプロパティを見る等すると分かるが、 vcredist_x86.exe のプロパティに記載されているものと一致しているらしい。 確かにずらす意味は無いので、こちらを見れば良いだろう。
よって、例えばこの様になる。
[Add.Code] msvcr90.dll=msvcr90.dll msvcp90.dll=msvcp90.dll atl90.dll=atl90.dll hoge.dll=hoge.dll [msvcr90.dll] hook=crt.cab_Installer FileVersion=9,0,30729,1 [msvcp90.dll] hook=crt.cab_Installer FileVersion=9,0,30729,1 [atl90.dll] hook=crt.cab_Installer FileVersion=9,0,30729,1 [crt.cab_Installer] file-win32-x86=vc9dll.cab run=%EXTRACT_DIR%vcredist_x86.exe [hoge.dll] file-win32-x86=thiscab clsid={XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} RegisterServer=yes FileVersion=1,0,0,1 - deploy 用 cab file に必要なものだけ含めて署名。
runtime library は上記の仕掛けによって入ったものと見なせるので、上記の例の場合に 必要なものは自前の dll と inf だけ。 hoge.dll と hoge.inf を hoge.cab に含めて署名する。
これで hoge.cab と vc9dll.cab を同一の場所に置けばいい。
