RFC7231のリファラに関するメモYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
前代未聞？RFC 7158が一瞬で廃止されてRFC 7159に！:Geekなぺーじ
3月2日より、ロンドンにてIETF 89が開催中ですが、IETFでRFC 7158が一瞬で廃止されるという珍事が発生しました。 どうも、2014年3月と記載すべきところを2013年3月としてしまったので、それを修正するためにRFC 7159が発行され、RFC 7158は即座に廃止されています。 RFC 7158とRFC 7159のdiffを見ると、見事に2013と2014の違いしかありません。 しかし、「本当にこれだけの違いで大丈夫なの？」と思える部分もあります。 たとえば、「Status of This Memo」Errataを記載する部分がRFC 7159において、Errataを「http://www.rfc-editor.org/info/rfc7158」としているのですが、正しくは「http://www.rfc-editor.org/info/rfc7159」だと思われます。 また
POST をリダイレクトすると GET になる件について調べた - 理系学生日記
とある事情により、POST リクエストをリダイレクトさせる必要が生じました。単純にリダイレクトさせてみたところ、リダイレクトはされるものの、POST リクエストに付与していた HTTP_BODY が取得できません。どうも、リダイレクト時に GET に変更されているみたいです。 ぼくは怒りに震えたものの、RFC 的にはどう振る舞うべきなんだ、各種ブラウザの振舞いはどうなっているんだ、ということが気になったのでまとめてみました。内容としては、 -POSTリクエストをリダイレクトするとGETされる？POSTされる? - はこべにっき ♨ の二番煎じになります。 先に結果を示しておくと、以下のとおりでした。 Status Code 期待動作 Firefox (25.0.1) Safari(7.0) Chrome (31.0) 301 POST GET GET GET 302 POST GET GE
「メールアドレスのルール」なんて使ってはいけない3つの理由 - めもおきば
定期的に繰り返される話題ですがまた盛り上がっているのできちんと書いておきます。 「通るべきメールアドレスが弾かれると激おこ」という前提で話を進めます。 問題点1. メールアドレスに関して、RFCなんてそもそも守られていない 2009年以前に登録されたDoCoMo携帯のメールアドレスなど、quoted-stringじゃないのにピリオド連続するものが実在している以上、彼らを許容するべきです。 今そこにある実装 >>(越えられない壁)>> RFC です。 問題点2. メールアドレスの国際化 @の左側(addr-spec)でUTF-8を利用できるようにするRFC5335が発行されています。これにより、通すべき文字が一気に増えます。 RFC5335 Internationalized Email Headers JPRSが国際化電子メールアドレスの標準化活動に貢献 / 株式会社日本レジストリサービス
「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を - 若くない何かの悩み
メールアドレスのルールのまとめ系のサイトの内容が間違っています。 なので、この類のまとめは安易に信じないように 、という注意喚起をしておきます。 追記（2013/11/27） twitterやはてブをみていたところ、「ユーザーへの啓蒙という観点ではまとめの内容間違ってない」というご意見をたくさんいただきましたので、補足をしておきますね。 どうも「ルール」と「トラブルを避けるためのガイドライン」が混同されているように思います。まとめで紹介されている内容がユーザ向けの「ガイドライン」なのであれば、「+ 記号使わせてよ」ぐらいしか文句はありません。 ですが、ほとんどのまとめは上記の内容を「ルール」として説明しています。ひどいものにはRFCに基づいてまとめを書いたようにミスリードさせる記事もありました。このような現状を憂い、このような記事を書いたのです。 そもそもこれに気づいた発端は@kusano
ジョーク RFC
[ TOP ] [ RFC ] ジョーク RFC とは？ 「ハッカーズ大辞典」 ( Jargon File の邦訳書 ) によれば インターネットでは、エープリルフールの悪ふざけは長年の伝統のようです。 以下、同書からの引用です。 AFJ// n. "April Fool's Joke"(4月バカのジョーク)の書き言葉でしか使われない略語。 エープリルフールの悪ふざけは、USENET と Internet で長年伝統として定着している。 実例は kremvaxを参照。事実エープリルフールの日(April Fool's Day) は、 ハッカーのネットワーク上で恒例の儀式が繰り広げられる唯一の祭日だ。 この伝統は、当然の様に RFC にも引き継がれており、 4 月 1 日には 真面目な RFC に混じってジョークのような RFC が発行されることがあるようです ( 同書の RFC の項を参照
どさにっき - /.j RSS
2006年5月22日(月) ■ 役所の常識、世間の非常識 _ 民間の駐車場に「契約車専用」というアクリル板があるのは珍しくないよね。 _ でも、民間の駐車場の一角に駐車スペースとは別にデカデカと「会計検査院専用洗車場」と書かれたアクリル板があるのは世間一般の常識からはずれてるよね。冗談じゃなくてほんとに洗車してるんだよね。っていうか、何で黒塗りの高級車があんなにたくさん必要なんだろうね。 _ 会計検査院：宿泊先予約など、随意契約で天下り先に発注。もっと追及してやってくださいまし。新聞の切り抜きに必要な知識・能力って何だろ？ ■ /.j RSS _ /.j の RSS にくだらん広告がいっぱい載るようになって、リンク先も行動調査用(たぶん)の URL をいったん経由してからでないとアクセスできないようになった。キモい。 _ ので、自分で RSS を生成するようにした。sh 以外のスクリプトを
BINDにプライベートアドレスの応答をさせる方法
cles::blog 平常心是道 blogs: cles::blog NP_cles() « Do itashi mashite :: Your account will expire in 1day. » 2007/09/28 BINDにプライベートアドレスの応答をさせる方法 bind rfc 134 7へぇ 先日、VPNが構築できたので仕上げにBINDを設定して、名前を使って末端同士が通信できるようにしてみました。zoneファイル自体は難なく作成できて、namd.confも書き換えたのですがなぜか名前が解決できないのでログを見てみると以下のようなログが残っていました。 named[22322]: client 192.168.30.2#4763: view vpn: RFC 1918 response from Internet for 254.30.168.192.in-addr
DNSラウンドロビンを使った時にアクセス・負荷が偏る話 - 元RX-7乗りの適当な日々
昨日に続き、アクセスが偏る系のエントリです。 なにかと議論のネタになるDNSラウンドロビンですが、今日はDNSラウンドロビンを使った時に、各IPアドレスにくるリクエスト数に偏りが出るという話。 DNSラウンドロビンで設定されているFQDNに、コマンドラインで"host"とか"nslookup"のコマンドを何度か実行すると、返ってくるIPアドレスリストの順序が入れ替わっていくことが確認できると思います。 基本的に、クライアントはそのIPアドレスリストの上(最初)からアクセスを行うため、これによって(一応)負荷分散が実現できるはずですが、特定環境のクライアントでは、ラウンドロビンとはならずに必ず特定のIPアドレスにアクセスするケースがあるのです。(既知の事実ですが。) この事は、Wikipediaの該当ページにも記載されています。 主にIPv6における宛先アドレス選択アルゴリズムとして定義され
DNS でラウンドロビンは当てにならない。 - JULY’s diary
モバイルでもDNSラウンドロビンはちゃんと動作しますか？ PCであれば、だいたいのブラウザが対応していると聞きますが、モバイルはどうなんでしょうか？ A、B、Cというサーバをラウンドロビンで動かした時に、Bが死んだとします。 その場合、PCはBに行かなくなると思いますが、携帯の場合はどうなんでしょうか？ 携帯はキャリアのプロキシ？か何かを通っていそうなので、ちゃんと動くのかが気になります。 また、ラウンドロビンの弱点は何ですか？ 今のところ気づいているのは、単に振り分けるだけだから1台に負荷が集中するかもしれないことくらいしかないです。 上の質問を見て、「あれっ、ラウンドロビンって、ブラウザのようなアプリケーションサイドで対応するものだっけ？ gethostbyname 辺りで勝手にやっていて、アプリ側は渡された IP で繋ぐだけでは？」と思っていたら、それは、もう古い話らしい。 0000
JavaScript ソースの MIME タイプ - odz buffer
header(”Content-type: text/javascript; charset: UTF-8″); JavaScript ソースのContent-typeって普通 application/x-javascript じゃね、とか思ってちょっと調べてみたら、text/javascript, text/ecmascript, application/javascript, application/ecmascript の4つが IANA に登録されていて、text/(java|ecma)script のほうは obsolete になっているでやんの。いつの間に、と思ったら今年の4月に RFC 4329 で公開されたらしい。ということはこれからは <script type="text/javascript"></script>じゃなく、 <script type="applicati
Geekなぺーじ : IPアドレスにまつわるチョイネタ
IPv4アドレスの例としては、上記IPv4アドレスを使えばいいわけですが、世の中を見ると結構好き勝手なIPv4アドレスを例として利用している事例が多いというのが現状ではないかと思います。 私が初めてこれを知ったのは、kazuさんのブログの「あどけない話：例として推奨されているドメイン名とIPアドレス」を読んだときです。 それまでは、知らなかったので、適当なIPv4アドレスを使ったサンプルを書いてしまってました。 申し訳ありません。。。 余談ですが、kazuさんは、私が「技術的に一生追いつけそうにない」と思っている凄い人の一人です。 こういった凄い方々を色々と見ていると、私が自分のサイト名に「Geek」という在らぬ単語を入れてしまったことを悔いていたりします。 以前から書き続けていますが、私は「ギーク」なんかじゃないです。サイト名は気のせいです。すみません。。。 というか、そういう「凄い」と
例として推奨されているドメイン名とIPアドレス - あどけない話
解説記事や発表資料で、ドメインの例を出す場合、example.jp等を使うことが推奨されているのを知っている人は多いでしょう。しかし、IPアドレスの方は知らない人もいるみたいです。ここでは両方について出典を示しながらまとめます。 知っていて別の例を使うのはいいのですが、知らないで別の例を使うのはよくないです。 gTLDのドメイン名の例 RFC2606で以下のように定められています。 3. Reserved Example Second Level Domain Names The Internet Assigned Numbers Authority (IANA) also currently has the following second level domain names reserved which can be used as examples. example.com exa
Cookie(クッキー)の届く範囲 (あいまいモード)
Cookieが届く範囲を再確認 別のページでCookieについて解説しましたが、 実際Cookieを利用したプログラムを作ると疑問に思えることも出てきます。 その一つとして、Cookieが届く範囲は？というものがあります。 発行されたサーバー（ホスト）に返信されるというのが基本ですが、 Cookieの仕様には「domain」や「path」というのがあったのを覚えてますでしょうか？ （なにそれ？という方は下記のW3CのRFCか前回の解説をどうぞ、、、） Cookieの仕様は下のリンクをどうぞ・・・ W3C (RFC 2109)HTTP State Management Mechanism Netscape HTTP Cookies Cookieの詳細については上のリンクで確認していただくとしても、 実際にプログラムを書く場合にどうやって使うの？という場面も多いと思います。 自分もCookie
Cookie 今昔物語 - はてなるせだいあり
概要 Cookie の不幸な歴史と現状、そして将来についてまとめた。 仕様はどこにあるか Web 上の様々な規格は、誰かが定め、それに皆が合わせるという形で動いている。しかし、Cookie の仕様は誰が決め、どこで規定されているか知っている人は、意外と少ないのではないかと思う。W3C や IETF だと思っている人が多いのではなかろうか。 正解を言ってしまうと、定めたのは 1994 年、Netscape Communications 社であり、文書は http://wp.netscape.com/newsref/std/cookie_spec.html で公開されていた。アクセスしてみればわかる通り、このページはもう存在しないし、Netscape 社自体が AOL に買収されており、今は Mozilla になったというか、消えてなくなっていることを知っている人は多いだろう。当時の文書は例に
RFC2045 Base64 で使用する文字の種類
Landscape トップページ | < 前の日 2005-03-25 2005-03-29 次の日 2005-03-30 > Landscape - エンジニアのメモ 2005-03-29 RFC2045 Base64 で使用する文字の種類 当サイト内を Google 検索できます * RFC2045 Base64 で使用する文字の種類この記事の直リンクURL: Permlink | この記事が属するカテゴリ: [メモ] [プログラミング] [RFC] バイナリデータをテキストデータ化する時によく使われる Base64 についてのメモ。 - Base64 で使用する文字の種類大文字と小文字の両方のアルファベットと、0から9までのアラビア数字、/ スラッシュと + プラス記号を主に使う。 = イコールは一行の文字数が足りないときのパディング(詰め物)として使う。 以下、使用する文字。 ab
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Loading...
RFC for the 7XX Range of HTTP Status codes - Developer Errors - joho/7XX-rfc · GitHub
「例」を書くときは example.com を使いましょう
fam.cx