Java 6のHttpCookieの野郎は、日本ではexpires指定ありのクッキーを処理できていない。 - 片っ端から忘れていけばいいじゃない。
(2009/08/26 13:04) 以前に「Java 6で、HttpURLConnectionをクッキーに対応させる手軽な方法。」という記事を書いたのですが、いざ本気でクッキーに対応したアプリケーションをJavaで書こうとすると、非常に残念であることがわかりました。 具体的には、日本で実行された場合に、HttpCookie がクッキーの「expires=」日時文字列の解析に常に失敗して、expires指定のあるクッキーの HttpCookie#getMaxAge() の値も常に 0 になってしまうのです。 そして、CookieStore の デフォルト実装である sun.net.www.protocol.http.InMemoryCookieStore は、maxAge が 0 のクッキーを保持してくれませんから、結果として、expires が指定されているクッキーは 日本では 一切保持
「Java SE 6完全攻略」第40回 Cookieを扱う その1
CookieはHTTPを使用したサーバ、クライアント間で、情報のやりとりをするために使われます。Cookieがセッション管理などに使用されていることは読者のみなさんもよくご存じですね。 JSPやServletではCookieを当たり前のように使うことができます。では、Java SEでクライアントを作成する場合はどうでしょう。 CookieはHTTPヘッダとして扱われます。java.net.URLConnectionクラスのgetHeaderFieldメソッドを使えば、サーバから送られてきたヘッダを取得することができるので、取得したヘッダからCookieを取り出すことが可能です。また、setRequestPropertyメソッドを使うことでサーバにCookieを付加して送信することもできます。 とはいうものの、URLConnectionクラスが作成されるたびに、getHeaderFieldメ
第1回 まずは「クッキー」を理解すべし
Webアプリケーションのぜい弱性がなかなかなくならない。メディアなどでも盛んに取り上げられているにもかかわらず，である。特に，セッション管理がからむアプリケーションのぜい弱性には，気付かないことが多い。具体的には「クロスサイト・リクエスト・フォージェリ」（CSRF），「セッション・フィクセーション」などである。これらはクロスサイト・スクリプティング，SQLインジェクションといった比較的メジャーなぜい弱性に比べて認知度が低く，対策も進んでいない。 原因の一つは，アプリケーションの開発者が原因を正しく理解していないこと。CSRFやセッション・フィクセーションについて言えば，セッション管理に使うクッキー（cookie）の動作を理解していないと対策が難しい。ところが最近の開発環境では，セッション管理の仕組みが隠ぺいされているため，必ずしもこの知識は要求されない。こうした開発者は容易にはぜい弱性に気
[ThinkIT] いまさら聞けないTomcat～JSPサーバ構築のキソ
Tomcatマスターになるために HTTP/HTMLを用いた静的ドキュメントの交換という目的からスタートしたインターネットは、産業や社会のコミュニケーションやパーソナライズされた情報を扱う媒体として発展してきています。こうした流れの中で、インターネットはリアルタイムのコンテンツ更新を求められるようになってきました。 検索エンジンや掲示板などはその一例です。こうしたWebアプリケーションを実現するためには、HTTPを介してリクエストを受け取り、リクエストに応じた処理を行った結果（動的コンテンツ）をリクエスト元に返す仕組みが必要になります。 動的コンテンツ提供のための仕組みの1つが「サーブレット/JSP」です。サーブレット/JSPは、Sun Microsystems（以下、Sun）によって開発されたサーバサイドのJava技術であり、オブジェクト指向に基づくプログラムの部品化の実現や、豊富なクラ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CookieHandler (Java Platform SE 6)
Webアクセスの基本---目次
