RFCの読み方
こんにちは。技術開発室の伊藤です。 ハートビーツではメールサーバを自社で運用しています。そのメールサーバの移設を実施するにあたり、移設を対応するチームでさまざまなメールの仕様を理解しておく必要がありました。 メールプロトコルの仕様についてはRFC（Request For Comments）が発行されているため、メールに関するRFCを読んでまとめる勉強会を行いました。 その際にRFCを読むにあたって知っておくとよいことがいくつかあったので紹介します。 RFCとは RFCとはIETF（Internet Engineering Task Force）というインターネット技術の標準化を推進する団体やその他の団体が発行している、インターネット標準や技術提供の文書です。もともとは非公式な文書であることを明確にするため、Request For Comments（コメント募集）という名前にしていたようです
DNS における Master/Slave vs Primary/Secondary の現状（2020/06） - suu-g's diary
BLM の関係でコンピュータ業界の Master / Slave という言葉遣いにもメスが入ろうとしているいま、 DNS ではどうなっているんだっけ、というのがふと気になった。 というのも mattn さんの blacklist/whitelist master/slave に関する情報集め を見たから。あとコメントもしたから。 で、調べて行ったところ、ひとことで言えば既に Primary / Secondary になってるんだけど、そもそもこの用語自体そんな使わないよな、と思ったのだけど、そのあたりを解説するのは元記事の関心ごとと全く違うってことで、改めて自分のブログの記事にしてみたというわけ。 DNS は趣味でしかないので、ツッコミ大歓迎です。 Primary/Secondary が正しい用語です 用語に困ったら RFC 8499 (Jan, 2019) が正しい参照先。こう書いてある
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べたAPIOAuthWeb TL;DR HTTP でトークンを利用した認証・認可をする手法として RFC 6750 がある OAuth に限らず、トークンを利用して認証・認可する機構の一部として Authorization: Bearer ヘッダを使うことができる 使い方について詳しくはこの記事の下のほうに書いた 要求 トークンを利用した認証・認可機構を持つ API を作りたい クライアントがトークンを HTTP リクエストに含めて送信し、サーバはトークンを検証してリソースへのアクセスを許可したい Authorization: Bearer トークン ヘッダでトークンを送る API あるよね、ああいうやつ 疑問 Authorization: Bearer ヘッダは OA
RailsでHTTP APIのエラーレスポンスを "problem detail" 形式で返却する - Qiita
Web API開発において、エラーをどういう形式で返却するか、というのは設計する際の悩みポイントかもしれません。エラーレスポンスの仕様の1つとして RFC7807 Problem Details for HTTP APIs があります。 この形式をサポートしつつ Rails や Sinatra でも使える Ruby ライブラリをこの度作りましたのでそのご紹介。その名も ProblemDetails. 本記事では Rails での使い方について。 ProblemDetailsの機能概要 gem では以下の機能をサポートしています。 RFC7807形式を実装したオブジェクトクラス Railsサポート: problem detail 形式でレスポンスする problem renderer Sinatraサポート: problem render function problem details 形
ネットワークバイトオーダーの公式な参照先はエイプリルフール:Geekなぺーじ
インターネットは、その場しのぎの拡張を繰り返して迷路のようになってしまった古い旅館のような側面があります。 インターネットは、インターネットプロトコル(Internet Protocol/IP)を使った通信によって成り立つ世界規模のネットワークですが、そこで使われる非常に多くのプロトコルが「ネットワークバイトオーダー(network byte order)」というデータ転送の順番を採用しています。 ネットワークバイトオーダーはビッグエンディアンという大きな桁を表すビットを含むバイトから最初に並べる方式を示す用語で、TCP/IPに関連する非常に多く(もしくは大半)のプロトコルが、ネットワークバイトオーダーを採用しています。 しかし、ネットワークバイトオーダーがTCP/IPの標準であることを示したRFCは存在しません。 そもそも、ネットワークバイトオーダーを明確に定義したRFCも存在しません。
Markdown in 2016 - Hack like a rolling stone
Markdown、あなたのすぐとなりに潜む問題 昨日は toc 拡張の話ついでに、現在の Sphinx と markdown を取り巻く環境について愚痴ったわけですが、Markdown 業界は 2016年のこの時期になっても、いまだに共通的な仕様が決まっていません。 2004年、John Gruber によって生み出された Markdown は、12歳を迎えた現在、さまざまな markdown 処理系を持っています。 そして、不幸にも実装によって markdown の処理はそれぞれ異なってしまっています。 これは Markdown の仕様が曖昧であることと、それぞれの処理系で文法の拡張を行っていることから来ています。 Markdown 処理系による違い Markdown の仕様が曖昧であることは、さまざまな混乱を生み出しました。 babelmark2 が示すように、同じマークアップであって
RFCの正規文書がXMLに:Geekなぺーじ
インターネットに関連するプロトコルなどを規定するRFC(Request For Comments)の正規文書のフォーマットが、これまでのplain-text ASCIIからXMLへと変わります。そのためのRFCが、RFC 7990 - RFC 7998として策定されました。 RFC 7990 RFC Format Framework RFC 7991 The "xml2rfc" Version 3 Vocabulary RFC 7992 HTML Format for RFCs RFC 7993 Cascading Style Sheets (CSS) Requirements for RFCs RFC 7994 Requirements for Plain-Text RFCs RFC 7995 PDF Format for RFCs RFC 7996 SVG Drawings for R
私のURLはあなたのURLとは違う : curl作者の語る、URLの仕様にまつわる苦言 | POSTD
1996年にcurlプロジェクトの先駆けとなるhttpgetを始めたとき、私は初めてURLパーサを書きました。当時はまだ、ユニバーサルアドレスは URL : Uniform Resource Locators と呼ばれていました。その仕様は1994年にIETFによって発行されたものでした。この”URL”という用語からインスピレーションを得てツールとプロジェクトに命名したのが curl でした。 URLという用語は後に事実上、 URI : Uniform Resource Identifiers (2005年発行)に変わりましたが、「オンラインでリソースを指定する文字列のための構文と、そのリソースを得るためのプロトコル」という、基本的な点は変わりませんでした。curlでは、この構文仕様RFC 3986の定義に従う”URL”を許容するとうたっていますが、それは厳密には正しくありません。その理由
RFC 7763: The text/markdown Media Type
Internet Engineering Task Force (IETF) S. Leonard Request for Comments: 7763 Penango, Inc. Category: Informational March 2016 ISSN: 2070-1721 The text/markdown Media Type Abstract This document registers the text/markdown media type for use with Markdown, a family of plain-text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. Status of This Memo This do
MIMEヘッダエンコーディングは複雑すぎてつらい - tmtms のメモ
これは NSEG Advent Calender の7日目の記事です(内容は NSEG とも長野とも関係ありませんが…)。 www.adventar.org メールの送信者(From)や件名(Subject)は本来ASCII(の一部の文字)しか書くことができないんですが、MIME(RFC2047)の登場によって日本語等の非ASCII文字を記述することができるようになりました。 とは言ってもメールアプリから見て日本語が表示できているだけで、内部的にはASCII文字にエンコードされています。MIMEヘッダエンコーディングと呼ばれています。 たとえば、「日本語」という文字列は =?utf-8?b?5pel5pys6Kqe?= や =?iso-2022-jp?b?GyRCRnxLXDhsGyhC?= に変換されています。 この処理が実は非常に複雑で、正しくエンコードされてない場合がかなりあります。
RFC 5234: Augmented BNF for Syntax Specifications: ABNF
Network Working Group D. Crocker, Ed. Request for Comments: 5234 Brandenburg InternetWorking STD: 68 P. Overell Obsoletes: 4234 THUS plc. Category: Standards Track January 2008 Augmented BNF for Syntax Specifications: ABNF Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please ref
RFC的に、HTTPヘッダってどんな値を使えるんでしたっけ？のメモ - 小野マトペの納豆ペペロンチーノ日記
Web APIを開発していると、HTTPのヘッダについてRFCにおける規約を確認しなきゃいけない場面がたまにあるので、今回調べたことをまとめた。 HTTP/1.1のRFC HTTP/1.1のRFCといえば、長らくRFC2616であったが、2014年にRFC7230〜7239が発行され、2616は廃止された。 RFC2616 ハイパーテキスト転送プロトコル -- HTTP/1.1 RFC7230〜RFC2739 HTTP/1.1 — RFC 7230 〜 7235 — 日本語訳 両者の変更点については、RFC 723xの付録に記述されているので参照のこと。Content-MD5が廃止されたり、ちょいちょい面白い。文章としても723xの方が分かりやすくなっているので、一度目を通しておくことをお勧めする。 HTTP/1.1 が更新された | The Long Wait あたらしいHTTPの話をし
HTTPステータスコードに追加された「308」とは？
2015年4月6日、HTTPの新たなステータスコードである「308 (Permanent Redirect)」がインターネット技術の標準化団体であるIETFによって「The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)」（RFC 7538）として策定された。 HTTPのステータスコードには、成功を示す200番台、ユーザー側が原因の失敗を示す400番台、サーバー側が原因の失敗を示す500番台などがある。今回仕様が追加された308を含む300番台は「リダイレクション」用に割り当てられており、HTTPの要求を完了させるために要求先とは異なるリソースを参照する必要があることをサーバーがクライアントに伝えるときに使われる。 もっとも使われるのは「304 (Not Modified)」だ。クライアントが持つキャッシュよ
encodeURIComponentが世界基準だと誤解してた話
URLをいじくるプログラムをいじっていて、仕様がよくわからなくて悩んだのでまとめます。 2/23: 追試部分を追記 2018/7/14: JavaScriptのURLSearchParamsと、GoのPathEscapeについて追記 ことの経緯 HTTPとはなんぞやとか、GETとPOSTがどうの、それぞれでパラメータがどういう経緯でウェブアプリケーション(とかCGI)に渡って来るのかぐらいは知っていました。で、ウェブでXHRでGETリクエストを送る場合にはJavaScriptのencodeURIComponent()で各パラメータをエンコードして、&でくっつけて、URLの末尾に?で付与すればいいんだよね？と思っていました。こんな感じに。 var finalUrl = [url, "?", encodeURIComponent("key"), "=", encodeURIComponent(
HTTP/2がRFCに:Geekなぺーじ
IETF HTTP Working GroupのChairであるMark Nottingham氏が、ブログで「HTTP/2 is Done」というタイトルで、HTTP/2がRFCとして公開されると述べています(番号はまだ発表されていません)。 HTTP/2は、GoogleのMike Belshe氏とRoberto Peon氏がSPDYのプロポーザルをIETFで提案したことから開始しています。IETFのhttpbis Working GroupにSPDY Protocolが提案されたのが2012年2月(draft-mbelshe-httpbis-spdy-00)なので、それから約3年です。 今のインターネットは、HTTPトラフィックの割合が非常に高いと言われているので、HTTPは、インターネットを構成する非常に重要なプロトコルであると言えます。そのような影響力が大きいプロトコルのバージョンア
意外と知られてないメールの7つの決まり事 -到達率のいいメールの書式設定の話- - 業界最安値、高到達率のメルマガ配信システムを作った
前置き メールの決まり事って言っても「目上の人に対してお疲れ様です。」を言わない、「ちゃんと、冒頭で名乗る」とかそういうことじゃなく。。。 電子メールは1970年ごろに開発されてから色々と仕様をインターネットを作ってきた偉い人達があれやこれやと決めてきました。 その、仕様をちゃんと守ってメールを作りましょうね。という話を書きます。 一括送信ガイドライン - Gmail ヘルプ にも、そのことは明記されています。相変わらずごちゃごちゃと書いていますので、話を抽出すると。 RFC5322に従ってね HTML規格に従ってね メールには Message-IDを付けてね メールヘッダに Precedence: bulk って付けて一括送信メールって教えてね リンク先ページやメールの送信者を隠蔽しないでね 本文に関係のある件名を付けてね ドメインは正しく書いてね という感じです。 いつものように一つ一
UUIDはなぜ、分散環境で好き勝手に生成しても衝突しないのか。RFC4122規格とUUIDの性質。
UUID の Version の見分け方 さきほどのPHPのプログラムは、パラメータにUUID_TYPE_RANDOMを渡しているので、バージョン4と思われます。 uuid_createのソースコードを覗いてみる ちょっと遊びの領域に突入しますが、uuid_createのソースコードを覗いてみます。一部を抜粋します。 /* {{{ proto string uuid_create([int uuid_type]) Generate a new UUID */ PHP_FUNCTION(uuid_create) { // ...(略)... do { uuid_t uuid; char uuid_str[37]; switch(uuid_type) { // ...(略)... case UUID_TYPE_DCE_RANDOM: uuid_generate_random(uuid); br
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RFC標準を調べるための知識やツール - Qiita
everyrfc.org
RFC7231のリファラに関するメモ
