あけましておめでとうございます。

今更ですが明けましておめでとうございます。

今年は何に注力するのか未定。

ともかく色々な技術に触れて見識を深めたい。

cookieがセットされない

最近cookieに悩まされたので。

var webReq = (HttpWebRequest)WebRequest.Create("http://www.aaa.co.jp");
var webRes = (HttpWebResponse)webReq.GetResponse();

という形で、レスポンスを取得するのはよくあるのだが
レスポンスが正しくセットされないことがたまにある。

原因として、以下の２点があるようである。
１．cookieのvalue にカンマが含まれている
例)HttpHeaderの一部
Set-Cookie : cookieA=a,b,c,d,e
<レスポンスにセットされるcookie>
・cookieA = a
※b,c,d,eが読み捨てられる。
   bとcとdとeというcookieが存在すると解析されている？

2．cookieのvalue にカンマが連続で含まれる
例)HttpHeaderの一部
Set-Cookie : cookieA=a,b,c,d,e
Set-Cookie : cookieB=a,,,c,d,e
Set-Cookie : cookieC=CCC
<レスポンスにセットされるcookie>
・cookieA = a
・cookieB = a
※cookieC自体がセットされない。

少なくともこのような傾向がある。
解決方法としては、レスポンス取得後、HttpHeaderからcookieを取得して
正規表現でどうにかして、cookieとその値を確実に取得して
レスポンスのcookieに書き込んであげるしかない。
その辺りは、サイトによると思うので、割愛。

cookieにカンマが含まれていると危険だ。
でもcookieの値にカンマが含まれているサイトって多いのか疑問である。。。

Win8が発売された夜中に思うこと

2012/10/26
いよいよWindows 8 がリリース。

10/20にMicrosoft(MS)のセミナーを受け色々情報を仕入れていたので、
次の月曜日にお昼を食べながら会社の人に展開。
その時に、Upgrade版が安いという話題になったのだが、
それは魅力的だがハードが元のままなので、Upgradeする意味は余りないよね
という話になった。
（→案の定、このことで騒いでいる人がいるみたい）

タッチパネルやジャイロなどのセンサー搭載のハードごと購入したほうが、
Win8の醍醐味を味わえるのではないだろうか。

（※Win8はUpgradeよりも新しいハードごと購入して使用することを強く薦めます!!!）

Windows7がリリースされた時よりも、MSの熱というか意気込みをすごい感じているので、その勢いに乗りたいところだが2台めのPCをどのタイミングで購入するのか悩み中である。

会社PCは期待できないんだよなー

寝る前に、むしゃくしゃしていたのでかなり適当な内容だが、
Win7リリース時よりも、Developerとして、より多くの選択肢が増えたのは
とても良いことであり、ビジネスチャンスは広がりそう。

UltraBookも頑張ってくれると、なお面白いことになりそうだ。

Javaって意外に不便

今のプロジェクトでたまたまJavaを使う機会があったのだが、
普段使用しているC#(というよりは .NetFramework)と比べて機能が少ないと感じてしまう。


文字列関係でも、Right、Left、Midにがいとうするのはないし、
ファイルのコピーも自分で実装しないとだめだし、
で結構不便。
あとはLINQと同様の機能ってないのかな。

.NetFrameworkにあるメソッドをJavaで作っていくことが多くなりそう。
余裕ができたら、そんな個人ライブラリを充実させていこう。

要求のエンティティが大きすぎるため、ページを表示できませんでした。

クライアント認証の設定を行ったWebサイトでのお話。

環境
Windows Servre 2008 R2 Standard
・IIS7.5
SSL設定あり。クライアント証明書を要求する設定。

このサイトに対して、アクセスすると最初は良いのだが、
適当な時間放置してから再度操作を行うと、次のエラーが表示されるようになってしまった。

<エラー内容>
要求のエンティティが大きすぎるため、ページを表示できませんでした。

<回避策>

IISのこのプロパティを変更すれば大丈夫なよう。

IISマネジャーで対象サイトを選択
↓
構成を選択
↓
system.webserver/ServerRuntime/
と辿る。
↓
uploadreadaheadsizeの値を大きくする。

・どのぐらい値を変更すれば良いのかが分からない。
・uploadreadaheadsizeの値を極端に小さくして、再現できたので
検証方法、対処方法がこれだけで済むのかが不明。
・web.configに書き込まないほうが良い？
といった課題はまだあるので
困っている人は参考程度にしてください。

<参考サイト>
http://technet.microsoft.com/ja-jp/library/cc737382(WS.10).aspx
http://forums.iis.net/p/1169257/1949057.aspx

ちなみに
"要求のエンティティが大きすぎるため、ページを表示できませんでした。"
ではなく
"Request Entity Too Large"
で探したほうが色々見つかった。
エラーメッセージをそのまま検索するとこはよくあるのだが、
英語にしたほうが見つかりやすいとは…
また一つ学んだ。

IISでのクライアント認証

WindowsServerにてCAを立ち上げ、それを利用してクライアント認証を行うとすると
１．クライアントにServerに要求を投げてもらう。
２．Serverで管理者が代理要求をして、秘密鍵をクライアントに配布する
の２パターンがあると思う。

１．だとクライアントに面倒な作業が入るし、
https://localhost/certsvr
の画面を公開しても良いのかという疑問と不安もある。
何よりあの画面はとっつきにくい。
その代わり、参考サイトが結構ある。

２．だと秘密鍵をどうやって、クライアントに渡すのか、
渡した秘密鍵が複製されないかなどといいた危険はあるが、
クライアントでの作業が少ないので、マニュアルの作成などが不要というメリットもある。
こちらだと参考となるサイトが見つからなかった。
なので覚書程度に、MSDNフォーラムでのやり取りをまとめてみた。
イメージとしては、シス担が証明書の要求・作成・配布をマニュアルで行なって
ユーザー（クライアント）には秘密鍵のインポートだけやってもらう感じ。

[テスト環境]
＜WebServer＞
・WinServer2008R2 Standard SP1 x64
IIS 7.5  自作サーバー証明書セット済み
Active Directory 証明書サービス追加済み
※クライアント認証が必要なWebサイトあり。

＜クライアント＞
・WinXP SP3 x86

1.Serverでがhttps://localhost/certsvr に接続してクライアント認証証明書を要求
  ★このとき、秘密キーをエクスポートできるようにして設定する。
2.Severの自作CAにて、保留中の要求を確認したら発行する。
3.発行後、秘密鍵をエクスポートする。………☆
4.出力した秘密鍵をクライアントPCに配布。
5.クライアントPCにて、☆でエクスポートした秘密鍵をダブルクリックして、
  証明書ストアにインポート。証明書ストアの"個人"に証明書をインポートできる。
6.クライアントPCのIEにて、https://WebServer/XXXX/XXX.aspx (仮)に接続
7.証明書を要求するポップアップが表示されるので、☆でインストールしたクライアント証明書を選択する。
8.接続OK！！！！！

クライアント認証が必要なWebページの設定や、1.のやり方は
下記の参考サイトをみてみてください。

＜参考サイト＞
http://msdn.microsoft.com/ja-jp/library/cc402157.aspx
http://d.hatena.ne.jp/replication/20100802/1280928631

上のままだと、WebサイトとCAが同じ所にあるので、非常にまずい。
次の目標はCAをWebサイトとは関係のない、サーバーに立ち上げて運用する
より現実的な方法をまとめあげることだ。

自宅でまとめているので、画面のハードコピーなどはありません。

TransactionScopeのComplete

TransactionScopeって便利だなーと思って使用していたら、
予想とは違う動作をしたので、焦って調べ直した。


勘違いポイント
＜Complete＝コミットではない＞
Completeはあくまでも、コミットする準備ができたと明示的に書くだけであり、
コミットするのはUsing句を終了するときである。
コミットできないときはUsing句の終了で例外が発生する。
よって、TransactionScopeはtry&catchで囲む必要性が高そうだ。


            using (var tran = new TransactionScope())
            {
                try
                {
                    //
                    // データアクセス関連の処理
                    //


                    tran.Complete();


                }
                catch (Exception)
                {
                    // 例外処理
                    throw;
                }
            }

よりは




            try
            {
                using (var tran = new TransactionScope())
                {
                    //
                    // データアクセス関連の処理
                    //


                    tran.Complete();


                }
            }
            catch (Exception)
            {
                // 例外処理
                throw;
            }

のほうが現実的な気がする。