BLM の関係でコンピュータ業界の Master / Slave という言葉遣いにもメスが入ろうとしているいま、 DNS ではどうなっているんだっけ、というのがふと気になった。 というのも mattn さんの blacklist/whitelist master/slave に関する情報集め を見たから。あとコメントもしたから。 で、調べて行ったところ、ひとことで言えば既に Primary / Secondary になってるんだけど、そもそもこの用語自体そんな使わないよな、と思ったのだけど、そのあたりを解説するのは元記事の関心ごとと全く違うってことで、改めて自分のブログの記事にしてみたというわけ。 DNS は趣味でしかないので、ツッコミ大歓迎です。 Primary/Secondary が正しい用語です 用語に困ったら RFC 8499 (Jan, 2019) が正しい参照先。こう書いてある
コンピュータの中で扱うときにはIPv6アドレスは128ビットの情報として扱われますが、その128ビットを人間が理解するために文字列で表記することもあります。 IPv4の場合は、「192.0.2.100」のように8ビットごとに「.（ドット）」で区切るドット付き十進表記 (dotted decimal notation)で表現されますが、IPv6の場合は16ビットごとに「2001:db8:11aa:22bb:33cc:44dd:55ee:66ff」のように「:（コロン）」区切りの十六進法で表現されます。 IPv6表記には省略を行うことを前提とした表記ルールがあります。 IPv6アドレスをテキストでそのまま全部書くと長くなりがちなためです。 IPv6の表記に関して注意が必要なのが、2006年に発行されたRFC 4291定義されたIPv6表記法では同じIPv6アドレスに対して複数の表記方法が存在す
DNSOP M. West Internet-Draft Google, Inc Updates: 6761 (if approved) August 6, 2017 Intended status: Standards Track Expires: February 7, 2018 Let 'localhost' be localhost. draft-west-let-localhost-be-localhost-04 Abstract This document updates RFC6761 by requiring that the domain "localhost." and any names falling within ".localhost." resolve to loopback addresses. This would allow other specific
418 I’m a tea potとは ステータスコード 418 I’m a tea potは、エイプリルフールに発行されたジョークRFCであるRFC2324「Hyper Text Coffee Pot Control Protocol」 で定義されているステータスコードです。 Googleでも 418 を返すURLがあります。 Error 418 (I’m a teapot)!? https://www.google.com/teapot 昨日、golangとnodejsにおいて、418 I’m a tea pot の実装を削除するIssue が投げられています。 golang: net/http: remove support for status code 418 I'm a Teapot nodejs: 418 I'm A Teapot #14644 Issue中でも書かれている通
RFC 6749 (The OAuth 2.0 Authorization Framework) で定義されている 4 つの認可フロー、および、リフレッシュトークンを用いてアクセストークンの再発行を受けるフローの図解及び動画です。動画は YouTube へのリンクとなっています。 English version: Diagrams And Movies Of All The OAuth 2.0 Flows 追記 (2019-07-02) 認可決定エンドポイントからクライアントに認可コードやアクセストークンを渡す方法については、別記事『OAuth 2.0 の認可レスポンスとリダイレクトに関する説明』で解説していますので、ご参照ください。 追記（2020-03-20） この記事の内容を含む、筆者本人による『OAuth & OIDC 入門編』解説動画を公開しました！ 1. 認可コードフロー RF
Network Working Group / Request for Comments: 3164 / 状態: 広報(Informational) C. Lonvick (Cisco Systems) 2001年8月 BSD syslogプロトコル この文書の状態 この文書の目的は、インターネット・コミュニティーに対して有用な情報を提供することである。インターネット標準を定めることを目的とするものではない。この文書は自由に配付して構わない。 著作権表示 Copyright (C) The Internet Society (2001). All Rights Reserved. 概要 この文書は、syslogプロトコルの実際の動作を調べ、記述したものである。syslogプロトコルは、ネットワークを介して何らかのイヴェントを通知するためのしくみとして、長年にわたって使われてきた。もともとは
1996年にcurlプロジェクトの先駆けとなるhttpgetを始めたとき、私は初めてURLパーサを書きました。当時はまだ、ユニバーサルアドレスは URL : Uniform Resource Locators と呼ばれていました。その仕様は1994年にIETFによって発行されたものでした。この”URL”という用語からインスピレーションを得てツールとプロジェクトに命名したのが curl でした。 URLという用語は後に事実上、 URI : Uniform Resource Identifiers (2005年発行)に変わりましたが、「オンラインでリソースを指定する文字列のための構文と、そのリソースを得るためのプロトコル」という、基本的な点は変わりませんでした。curlでは、この構文仕様RFC 3986の定義に従う”URL”を許容するとうたっていますが、それは厳密には正しくありません。その理由
HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた？よし、それなら 200 を返しましょう。ページが存在しない？それなら 404 です。他のページにユーザをリダイレクトしたい？ 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳：HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200
HTTPステータスコード451(政治的な検閲)が正式に承認される
mnot’s blog: Why 451? draft-ietf-httpbis-legally-restricted-status-04 HTTPステータスコード451がIETFで正式に承認された。近いうちにRFCとしても発行される。 元ネタは、Ray BradburyのFahrenheit 451(華氏451)というタイトルの小説で、これはディストピアな検閲社会を描いている。 451の意味は、403(禁止/権限がない)と似ているが、正確な意味は、ドラフトを引用すると、以下の通り。 このドキュメントはサーバーオペレーターが、あるリソース、あるいはあるリソースを含むリソース群に対し、閲覧を検閲するよう法的な命令を受け取った時に使うHypertext Transfer Protocol(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の話をし
クライアントから 「Windows7にするとカンマ区切りの複数宛先が機能しないので、セミコロンに直して欲しい」 と依頼があって 「はて？セミコロンで複数宛先を区切るなんてあまり聞いたことないな」 とか思っていたら、RFCには書かれているようだ。 RFC5322によると、複数のメールアドレスを以下のような記述でgroupとしてまとめることが出来る。 foobar:[email protected],[email protected]; このまとめられたものを、addressとして扱い、addressごとの区切りがセミコロンなわけだ。 addressであるひとまとまりのgroupでまとめた個別のメールアドレスであるmailboxを区切るのにカンマが用いられることになる。 RFC 5322 - Internet Message Format Appendix A.1.3. Group Addresses
サイトをコーヒー風に判定。目指すは究極のティーポット？！一言で言えば「サイト診断ツール」です。 好きなサイトのURLを入れると、採点結果を表示します。 採点結果はコーヒーの種類や価格で表現します。 まれに紅茶が出てきます。 よくページが見つからなかった時に「404 Not Found」とか表示されます。 この404はHTTPのステータスコードと呼ばれるものです。 他にもアクセス拒否された時に「403 Forbidden」が出たり、Perlがエラーになった時に「500 Internal Server Error」が出たりします。 これら「403」や「500」もHTTPのステータスコードです。 エラーだけとは限りません。 普通にページが開いた場合も、成功を意味する「200」というステータスコードを、アナタのPCは受け取っているのです。 目には見えませんが。 HTTPのステ
Re:は、電子メールやネットニュースの「返信」を意味する語である。 文字上の表現手段であり、読み方が定義されていないため正確な発音は存在しないが、あえて発音される際には、「リ」や「リー」もしくは「レ」や「レー」などと発音されている。マルチバイトの文字使用環境においても、必ず1バイトのいわゆる半角英字で記述される。 元々は、英語圏において文通の返信の表現として用いられていたという記録が1707年のオックスフォード英語辞典に残っていることから、それよりも古い時代から用いられていたのではないかと考えられる。英語圏のビジネスレターなどでは、現在も「…について」(regarding)の意味で表題に用いられることがある。 一方で、現在用いられている「Re:」はコンピュータ用語からの転用であることが多い。1972年、アメリカのAT&Tベル研究所において電子メールの策定が行われた際に、返信時のタイトルを標
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
