HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
諸君、私はステータスコードが好きだ - Really Saying Something
HTTPステータスコード - Wikipedia タイトルの通りなんですが、私はステータスコードというものがなぜかとても好きです。技術的な理解は追いついていないのですが、一覧を眺めるだけで相当楽しい。図書館の分類や競馬、歴代の◯◯、みたいな、ある範囲が定められていてその中の情報が分類されているという状況がどうやらとても好きみたいです。分類するのも好きだしされたものを見てるのも良い。 HTTPステータスコードは、HTTPにおいてWebサーバからのレスポンスの意味を表現する3桁の数字からなるコードで、RFC 2616、RFC 7231等によって定められている。 HTTPステータスコード - Wikipedia で、なんとなくステータスコードを取り上げた記事なんかをはてなブックマークでブックマークしておくのですが、ふと振り返ったら結構な量があったので、誰得かというと私得なんですけど、紹介してみた
Name Constraints を使った独自CAの運用手順
ウェブブラウザが新機能をHTTPSでしか有効にしないことが多くなってきたので、開発環境でもHTTPSを使いたい。でも、開発環境用にサーバ証明書を買うのは手間。Let's Encryptも運用がめんどくさいとか、社内からしかアクセスできないサーバへの証明書発行が難しいとかいろいろあるし…ってそこでName Constraintsを使った独自CAですよ奥さん。 Name Constraints が何であるかについては、以前オレオレ認証局の適切な運用とName Constraintsに書いたとおり。 本稿では、Name Constraintsを使うCAの運用手順を説明する。 1. CA鍵と証明書の作成 1.1. CAの秘密鍵を作成 % openssl genrsa -out ca.key 2048 1.2. openssl.cnfにCA証明書に設定する属性を指定するセクションを追記 [priva
Which should I use: Starman or Starlet?
A discussion came up on #plack IRC channel earlier, and we realize that there’s no good (official) documentation available to address the differences between the two popular Plack HTTP servers, Starman and Starlet. Besides the similarity in their names, they are actually similar in what they do: they do serve HTTP requests, and the process model is pre-forked (i.e. fork off a number of HTTP worker
TCP 3-way handshakeのレイテンシ軽減のためのTCP_DEFER_ACCEPTソケットオプション - ゆううきブログ
2013/10/22 追記した． Starletのコード読んでてlistening socketにTCP_DEFER_ACCEPTとかいうオプション渡してたので、これ何だって思って調べた． TCPに特に詳しいわけではないので理解に誤りがあるかもしれない． package Starlet::Server; ... # set defer accept if ($^O eq 'linux') { setsockopt($self->{listen_sock}, IPPROTO_TCP, 9, 1) # 9がTCP_DEFER_ACCEPTを表す and $self->{_using_defer_accept} = 1; } ... TCP_DEFER_ACCEPTはLinux 2.4から導入されている． Linux 2.6.32から挙動が若干変わっているらしい． (linux の TCP_DE
告白されたときの正しいステータスコードの返しかた、読みかた - As Sloth As Possible
今日は秋らしいよいお天気だったので、それとは特に関係なく今日も今日とてぼーっとディスプレイに向かっていたところ、こんな記事を見付けた。 勇気を出して告白！ その返事で覚えるHTTPステータス・コード あらあらまあまあ。なんだか俺、この記者の方にシンパシーを覚えるよ。 この手のネタは大好物なのだけど、404はお断りの返事ちゃうやん、てか断り方だけでも何パターンもあるんやで、とうずうずしてきたので便乗して考えてみることにした。例によって400系レスポンスに偏ってるのはお約束。しかたないよねー。告白のレスポンスなんて受けとる方でも返す方でも400系しか知らないもん。ごめん嘘だ。503（「お前本当にタイミング悪いな」）返したことある。再リクエストはありませんでした。200？ああ、そんなステータスコードもありましたね。おいしいのかな。使ってみたいです。 （予想外に反響があったので追記）見ての通り全部
WebDAV - Wikipedia
WebDAV（Web-based Distributed Authoring and Versioning、ウェブダブ）はHypertext Transfer Protocolを拡張したもので、Webサーバ上のファイル管理を目的とした分散ファイルシステムを実現するプロトコルである。 概要[編集] WebDAVは、Webサーバに対して直接ファイルのコピーや削除を行ったり、ファイル所有者や更新日時などのファイル情報を取得・設定するといった機能を持つ分散ファイルシステムで、HTTP 1.1を拡張したプロトコルで実現される。元々はファイルのバージョン管理機能も内包していたが、後に RFC 3253 で定義されたDelta-Vに分離された。 マイクロソフトによって最初に開発され、1999年2月に RFC 2518 が発表された。2007年6月に発表された RFC 4918 が2008年1月現在最新の
Hypertext Transfer Protocol - Wikipedia
Hypertext Transfer Protocol（ハイパーテキスト・トランスファー・プロトコル、HTTP）はアプリ間コネクション上のリクエスト/レスポンス型・ステートレス・メッセージ指向通信プロトコルである[1]。 概要[編集] TCPやQUICはアプリケーション間のコネクション型通信を提供する。HTTPはこのコネクション上を、リソース要望と返答が、メッセージ単位で、1往復のクライアントリクエスト&サーバーレスポンスという形で通信される、と定めたプロトコルである[1]。 HTTPの発明により、インターネット上でのリソース公開とアクセスが容易になった。クライアントがサーバーとコネクションを確立し1つのHTTPメッセージを書いて送るだけで、サーバー上のリソースがHTTPメッセージとして帰ってくる。ゆえにHTTPで公開されるあらゆるリソースにHTTPという単一の手法でアクセスできるようにな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Referer | 鳩丸ぐろっさり (用語集)
Studying HTTP
[Studying HTTP] HTTP Header Fields
bulkitem.com
株式会社スタイルズ
株式会社スタイルズ
※借りれるローン？！※お金も仕事もない時に頼れる金融会社！