新しいHTTP拡張
こんにちはインフラの後藤です。 昨年、初めてIETFにHTTPの拡張仕様 "The PRELOAD Frame Extension"を提案したので、それについて説明してみたいと思います。 仕様の提案とは そもそも「HTTPの拡張仕様を提案した」とはどういうことか簡単に補足します。 HTTPやTLSの標準化はIETFという組織で行われています。IETFへの仕様の提案は、基本的にはInternet-Draftを出すことによって行います。このInternet-Draftを出し、各ワーキンググループのメーリングリストで議論を行うのが一般的な流れです。 個人の書いたInternet-DraftはIndividual Draftと呼ばれ、誰でも出すことが出来ます。会員のような仕組みはなく、何かしらの審査もありません。適切なフォーマットで作成すればWeb上の提出フォームから提出するだけです。もちろん提案
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べたAPIOAuthWeb TL;DR HTTP でトークンを利用した認証・認可をする手法として RFC 6750 がある OAuth に限らず、トークンを利用して認証・認可する機構の一部として Authorization: Bearer ヘッダを使うことができる 使い方について詳しくはこの記事の下のほうに書いた 要求 トークンを利用した認証・認可機構を持つ API を作りたい クライアントがトークンを HTTP リクエストに含めて送信し、サーバはトークンを検証してリソースへのアクセスを許可したい Authorization: Bearer トークン ヘッダでトークンを送る API あるよね、ああいうやつ 疑問 Authorization: Bearer ヘッダは OA
MessagePackがIETF標準化に巻き込まれてる件について:Geekなぺーじ
ここ数日、MessagePackがIETFにおける標準化に巻き込まれてザワザワしています。 何が起きているかというと、MessagePackプロジェクトとは関係が無い第三者がIETFで派生物の標準化を進めようとしています(binarypack、Informational RFCとして)。 binarypackは、自らをMessagePackの派生であるとしながらも、MessagePackとの後方互換性が無いものです。 MessagePack is in danger! binarypackのInternet-Draftを提出しているのは、coreと6lowpanのchairです。 Chairであるかどうかが議論そのものに与える影響はそこまで大きくないとも言えますが、少なくともIETFでの話の進め方に精通した人物であることは確かです。 ただ、今回のInternet-Draftは、その人物がC
DewN RFC util
RFC Utilv3.2 - 03.19.2001 derrick_ on freenode.net Simple perl5 util for searching and alternately displaying RFC's. Why speed. i hate using the mouse and poking through web pages can take forever. i like to stay in a console or xterm for quickness when i can.. now any rfc is one or two commands away. What it does This tool will allow you to specify a number of an RFC, or a string that you're
ちょっとしたメモ - JSONがRFCに
JSONの文法などについて、今年の2月1月からインターネットドラフト（I-D）が出されているが、はやくもInformational RFCとすることが決まった（I-Dは現在04版draft-crockford-jsonorg-json-04.txt）。MIMEタイプはapplication/jsonとされている。 このI-D/RFCは、JSONの構文とMIMEタイプをオフィシャルな形で定義しようというもので、内容は基本的には既に知られている文法と違いはない。大まかに言えば、次のようなことが書かれている。 JSONは4つの基本型（string, number, boolean, null）と、2つの構造型（object, array）で表現される。 objectは、名前:値 の組の順不同のコレクションで、これらの組を , で区切り、{ と } で囲む。名前はstringで、値は上記6つの型の
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.ietf.org/rfc/rfc3330.txt
http://attrition.org/tools/src/rfc.pl
https://www.ietf.org/rfc/rfc2550.txt
https://www.ietf.org/rfc/rfc5016.txt
https://www.rfc-editor.org/rfc/rfc3330.txt
http://www.age.ne.jp/x/sf/HT/HTML/RFC1866J.TXT
Ｑ符号・略符号
https://www.rfc-editor.org/rfc/rfc4180.txt