今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
実験用のDNSサーバを構築する場合は、例示／実験用のドメイン名を利用するとよい。このような用途に利用できるトップレベルドメイン名としては「example.com」「example.org」がある。日本向けドメインとしては「example.jp」「example.co.jp」「ドメイン名例.jp」などがある。 解説 DNSサーバを導入する場合、一般的には、正式なドメイン名を取得してそれを利用する。例えば社内にActive Directoryを導入したり、インターネットメールサーバなどを導入したりする場合、自社の組織名や実現するサービス、商品、ブランドなどに合わせてドメイン名を取得し、そのドメイン名を利用してDNSサーバをセットアップする。 だがテストや調査などの目的で、暫定的にDNSサーバシステムを構築する場合、いちいちドメイン名を取得するのは現実的ではない。面倒だからというだけでなく、テス
「LT駆動開発 15 - 水光紫陽花」に行ってきました。 LT駆動開発というのは参加者がそれぞれLT(ライトニングトーク)をして参加者自身が学ぼうという勉強会らしいです。 今回僕は「NAT超えってなんぞや」というタイトルで発表しました。 今回は時間上の都合で大まかな動作概要しか説明する事ができませんでしたが、詳細な仕様についてはRFCを参照していただければ幸いです。 STUNはRFC5769・RFC5389・RFC5780、TURNはRFC6156・RFC6062・RFC5766、ICEはRFC5245・RFC6544などに対応しています。 LT駆動開発はほぼ毎月開催予定ですが、ネタ系から技術系まで幅広いジャンルを受け入れてくれる雰囲気なので興味があれば参加してみてください。
![NAT超えってなんぞや [LT駆動開発 15] - ねむむ日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/1352ba062f0b5f69b958c876728309752b317335/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fogimage.blog.st-hatena.com%2F12921228815714737255%2F8454420450096692187%2F1443956530)
とある事情により、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
定期的に繰り返される話題ですがまた盛り上がっているのできちんと書いておきます。 「通るべきメールアドレスが弾かれると激おこ」という前提で話を進めます。 問題点1. メールアドレスに関して、RFCなんてそもそも守られていない 2009年以前に登録されたDoCoMo携帯のメールアドレスなど、quoted-stringじゃないのにピリオド連続するものが実在している以上、彼らを許容するべきです。 今そこにある実装 >>(越えられない壁)>> RFC です。 問題点2. メールアドレスの国際化 @の左側(addr-spec)でUTF-8を利用できるようにするRFC5335が発行されています。これにより、通すべき文字が一気に増えます。 RFC5335 Internationalized Email Headers JPRSが国際化電子メールアドレスの標準化活動に貢献 / 株式会社日本レジストリサービス
メールアドレスのルールのまとめ系のサイトの内容が間違っています。 なので、この類のまとめは安易に信じないように 、という注意喚起をしておきます。 追記（2013/11/27） twitterやはてブをみていたところ、「ユーザーへの啓蒙という観点ではまとめの内容間違ってない」というご意見をたくさんいただきましたので、補足をしておきますね。 どうも「ルール」と「トラブルを避けるためのガイドライン」が混同されているように思います。まとめで紹介されている内容がユーザ向けの「ガイドライン」なのであれば、「+ 記号使わせてよ」ぐらいしか文句はありません。 ですが、ほとんどのまとめは上記の内容を「ルール」として説明しています。ひどいものにはRFCに基づいてまとめを書いたようにミスリードさせる記事もありました。このような現状を憂い、このような記事を書いたのです。 そもそもこれに気づいた発端は@kusano
このページでは、インターネットでホームページなどをブラウジングするときに利用するHTTPプロトコルについて説明しています。 概要 HTTPプロトコルとは、Hypertext Transfer Protocolの略で、インターネットでホームページなどをブラウジングするときに利用しているプロトコルです。 HTTPプロトコルは、TCP/IP上のプロトコルで、通常80番ポートを使ってアクセスします。 詳細な定義は、以下のRFCで定義されています。 RFC-1945 HTTP/1.0 RFC-2068 HTTP/1.1 基本的に、メッセージを要求(リクエスト)し、その応答結果(レスポンス)を表示するだけです。 HTTPのアクセスログ ApacheなどのWebサーバのログを見ると、リクエストとレスポンスが、以下の形式で出力されます。 アクセスログの書式 アクセス元 - - [アクセス時間] "メソッド
RFC 822 - STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES RFC # 822 Obsoletes: RFC #733 (NIC #41952) STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES August 13, 1982 Revised by David H. Crocker Dept. of Electrical Engineering University of Delaware, Newark, DE 19711 Network: DCrocker @ UDel-Relay Standard for ARPA Internet Text Messages TABLE OF CONTENTS PREFACE ......................
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
