iCalendar 仕様
iCalendar 仕様 iCalendar コンテンツの作成にとりあえず役立ちそうな情報の抜書き。（正確な仕様は RFC にあたること） 目次 仕様書 全般 構造 詳細 BEGIN, END VCALENDAR VTIMEZONE VALARM VEVENT テンプレート 実装 仕様書 iCalendar は RFC で定義されている。 RFC2445 (November 1998) Internet Calendaring and Scheduling Core Object Specification (iCalendar) RFC2446 (November 1998) iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Jo
HTTP/2、IETFの標準化プロセスが完了しRFCに。16年ぶりにHTTPがバージョンアップ
16年ぶりとなるHTTPの新しいバージョン、HTTP/2の標準化プロセスが2月18日付けで完了し、RFCとなりました。 IETFのブログでの報告。 HTTP/2 Approved | IETF Blog IETF HTTP Working Groupのチェア、Mark Nottingham氏のブログでの報告。 mnot’s blog: HTTP/2 is Done HTTP/2は昨年、2014年8月にHTTPbisワーキンググループのラストコールとなり、12月にIETFのステアリンググループであるIESGがRFCのための最終検討に入っていました。 HTTP/2は、現在広く使われているHTTP/1.1と互換性を保ちつつ、通信による遅延をできるだけ小さくし、ネットワーク帯域を効率的に使うために非同期で通信を多重化することなどによって、より高速な通信を実現することを目指したものです。 もともとG
<?phpタグが無くなる日 〜PHPの開発プロセス〜
PHPスクリプトを記述する際に使われる<?phpタグの利用をオプションで有効無効を切り替えるようにするという仕様がPHPの開発コミュニティでの議論に挙がっています。 この仕様変更が実装された場合、PHPスクリプトには必ず<?phpのタグがあるという前提条件が変わる事になります。 まずこの議論がどのような形で行われているのでしょうか？ご存知でない方もいるかと思いますが、PHPの文法や機能へどのような変更を加えたいか、という議論はRFC (Request For Comment)という形でパブリックに行われています。Wikiページに仕様や背景、実際のパッチなどを添付し、開発者やユーザーからの投票を行った結果を元に実際にPHP本体への変更を行うかどうかが決定されています。 過去に実装された機能の際の例などと一緒に見てみましょう。 Array Short Syntax # 従来の記述の場合 $a
強烈なDNSキャッシュポイズニング手法が公開される:Geekなぺーじ
本日、JPRSが緊急の注意喚起を公表しました。 緊急）キャッシュポイズニング攻撃の危険性増加に伴うDNSサーバーの設定再確認について（2014年4月15日公開）- 問い合わせUDPポートのランダム化の速やかな確認・対応を強く推奨 それに対して、2月中旬に脆弱性を発見してJPRSへと報告していた鈴木氏(脆弱性は前野氏との共同発見)が、JPRSの注意喚起では「危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません」として、以下の情報を公開しています。 開いたパンドラの箱 - 長年放置されてきたDNSの恐るべき欠陥が明らかに キャッシュポイズニングの開いたパンドラの箱 キャッシュポイズニングの開いたパンドラの箱 - 2 - 本来であれば、より上位からの正規の回答が優先されなければならないはずなのに、下位側が優先される仕様になっているので、偽装されたデータが優先されてしまう
sinkin' in the rain - PHPでCSV文字列を生成する
PHPでCSV文字列を生成する PHPで、改行やダブルクォートが含まれる値はエスケープするExcel風の（あるいはRFC 4180の）CSV文字列を取得する方法がよくわからなかった。 とりあえず「Perlメモ - 値のリストから CSV形式に変換する」風に処理することにして、エスケープする関数を作っておくことにする。 /** * エスケープ済みのCSV出力に適した値を取得する * ・RFC4180の第2項参照、基本的にExcel互換のクォートとエスケープを行う * * @param string $value * @return string $value */ function get_csv_quoted_value($value) { if (! is_string($value)) return $value; $value = preg_replace(’/“/’, ’”“’,
Same-Origin Policy とは何なのか。 - 葉っぱ日記
ちょっと凝ったWebアプリケーションを作成していたり、あるいはWebのセキュリティに関わっている人ならば「Same-Origin Policy」(SOP)という言葉を一度は聞いたことがあると思います。日本語では「同一生成元ポリシー」あるいは「同一生成源ポリシー」などと訳されることもありますが、個人的には「オリジン」は固有の概念を表す語なので下手に訳さず「同一オリジンポリシー」と書いておくのが好きです。 さて、この「オリジン」とは何なのかという話ですが、これは「RFC 6454 - The Web Origin Concept」で定められており、端的に言うと「スキーム、ホスト、ポート」の組み合わせをオリジンと定め、それらが同じものは同一のオリジンとして同じ保護範囲のリソースとして取り扱うということです。 例えば、http://example.jp/fooとhttp://example.jp:
ついにRFCに登場！Webサーバとの双方向通信を実現する「WebSocket」 - builder
次世代のWebアプリケーションの中核を担う技術として「HTML5」に注目が集まっているが、それと並んで期待されている技術に「WebSocket」がある。 IETFとW3Cによって仕様の策定が進められており、最初の提案以来幾度もの改訂を経て、2011年12月11日にそのプロトコル仕様がRFCのProposed Standard（RFC 6455）となった。 AjaxからComet、そしてWebSocketへ WebSocketはウェブサーバとブラウザが直接コネクションを張って双方向通信するための技術規格である。HTTPとは異なる独自の軽量プロトコルによって通信を行うため、オーバーヘッドが小さく、長時間に渡って通信する場合でもHTTPコネクションを占有する必要がないというメリットがある。 WebSocketが生まれた背景には、サーバとブラウザがもっとリアルタイムに通信して情報の配信や更新を行え
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
