新しいHTTPメソッド、QUERYメソッドの仕様 - ASnoKaze blog
新しいHTTPメソッドを定義する「The HTTP QUERY Method」という提案仕様が議論されています。 もともとは、SEARCHメソッドという呼び名が候補としてあげられていましたが、長い議論ののち、一旦QUERYと呼ぶ方向となっております。最終的なFixについては、この draft 02の公開とともに改めてコンセンサスを求めた後に行われます。 QUERYメソッド 「GETリクエストにボディを付けたいという」という質問は長らく有りました。しかし、GETやHEADリクエストでボディをつけることは非推奨となっています (参考URL)。 そのような要望のなかで、リクエストでボディを含められる冪等性の保証された新しいHTTPメソッドが検討されました。それがQUERYメソッドです。冪等性があるため、ブラウザやProxyは自動でリトライすることができます。(なお、POSTはセマンティクス上冪等
予約済みドメイン (.example, .localhost, .test) について | blog.jxck.io
Intro 特別なドメインとして予約され、特定の用途で使用可能なドメインとして、 .example .localhost .test などがある。 localhost の Draft や、 gTLD である .dev が Chrome で Preload HSTS になったなどの動きを踏まえ、これらの意味や用途を解説する。 ドメインを利用する上での注意 ドメインは、レジストラなどを通じて取得するため、インターネット上では好き勝手に取得することはできない。 しかし、自分で設定可能な DNS や hosts ファイルなどを使えば、任意のドメインを任意のアドレスに解決させることができる。 例えば、自分が適当にリクエストのテストを行うためのドメインを hosts ファイルに設定し、ループバックアドレスに解決して流していたとする。 このドメインがたまたま実在するものだった場合、そのテストを他のユーザ
HTTPで「418 I’m a tea pot」を実装してはいけない(2018/10/18追記) - Qiita
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中でも書かれている通
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
GoogleがオープンソースのRPCフレームワーク「gRPC 1.0」を発表 | OSDN Magazine
Googleは8月23日、オープンソースのRPC（リモートプロシージャコール）フレームワークの最新版「gRPC 1.0」公開を発表した。HTTP/2に対応し、大規模な分散システム向けの機能を備えるもので、運用環境で利用できるとしている。 gRPCはGoogleが2015年に発表したRPC（リモートプロシージャコール）フレームワーク。HTTP/2を標準とし、クラウド、マイクロサービスなど最新の利用に適したサーバー間通信プロトコルを目指す。それまで「Stubby」として社内開発、利用されていたものをオープンソースで公開した。同社ではgRPCを利用して毎秒100億単位のリクエストを処理しているという。 双方向ストリーミング、フロー制御、ヘッダー圧縮、多重リクエストなどの機能を持つ。フレームワーク内で複雑な処理を行うため、分散システムでの接続、運用、デバッグをローカルでの関数呼び出しのように容易に
Webの成功理由は制約 ８つしかないHTTPメソッド
Tweet Tweet前回は、TCP/IPをベースとしたプロトコルであるHTTPの基本についてまとめた。ここでは、Webの成功理由とも言われる8つのHTTPメソッド、特にGET、POST、PUT、DELETE、HEAD、OPTIONSについて説明する。 １ 8つしかないメソッド HTTPには、クライアントが行いたい処理をサーバに伝えるという重要な役割がある。HTTP 1.1においてその役割を果たすのが、以下の8つのメソッドである。ここでは、ほとんど使われていないTRACEとCONNECTを除いた6つのメソッドについて解説する。 GET ：リソースの取得 POST ：子リソースの作成、リソースへのデータの追加、その他の処理 PUT ：リソースの更新、リソースの作成 DELETE ：リソースの削除 HEAD ：リソースのヘッダ（メタデータ）の取得 OPTIONS ：リソー
HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
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
ページを削除したときは404と410のどちらを返すべきか？ => どちらでもいい
[レベル: 初〜中級] ページを削除したときには、404と410のどちらのHTTPステータスコードを返すべきなのでしょうか？ 結論を一言でいえば、Googleにおいてはどちらでも構いません。 再クロール率にも影響しません。 Googleのミューラー氏による説明 GoogleのJohn Mueller（ジョン・ミューラー）は、ユーザーから受け取った質問メールを引用して、404と410のGoogleの扱いについてGoogle+で説明しました。 I have a large site and removed lots of irrelevant pages for good. Should I return 404 or 410? What’s better for my “crawl budget”? (more from the depths of my inbox) The 410 (“G
HTTPリクエストを減らすために【序章】HTTPリクエストは甘え - MOL
このシリーズはHTTPリクエストの理解を通じてWebパフォーマンスの重要性について考える5章構成になっている。 【序章】HTTPリクエストは甘え 【CSS Sprite編】スプライト地獄からの解放 【WebFont編】ドラッグ＆ドロップしてコマンド叩いてウェーイ 【DataURI編】遅延ロードでレンダリングブロックを回避 【終章】我々には1000msの猶予しか残されていない 1日目は、HTTPリクエストの概要について説明する。 例えに、私のポートフォリオページ（t32k.me）が表示されるまでの流れを見ていく。まず、検索からでも方法はなんでもよいが、ブラウザのURLバーにt32k.meと打ち込んでアクセスする。そのページを見にいくということは、つまりt32k.meに対してHTTPスキームでリクエストするということを意味している。 クライアントであるブラウザは入力されたURLを判断して、リソ
先輩と覚える HTTP ステータスコード
gistfile1.md 先輩に学ぶ HTTP Status Code 超雑にまとめました。修正してください。 登場人物 アプリケーション先輩: いつも忙しい。横に広がるのが得意(デブじゃない)。 後輩: 頼んでばっかしで役に立たない。 サーバー先輩: アプリケーション先輩と仲がいい。Unix Socket でつながるくらい仲良し。 プロクシ先輩: アプリケーション先輩とかサーバー先輩と後輩の間を取り持って代わりに伝えたりしてくれる。たまに勝手にレスポンスを書き換える。 1xx 系 100 Continue 後輩「あ、先輩！お願いが！」 アプリケーション先輩「おー、聞いてやる。詳しく話せ」 101 Switching Protocols 後輩「せんぱーい、お願いなんですけどー」 アプリケーション先輩「ちょっと待て、お前 HTTP 1.0 で喋るな、 HTTP 1.1 か TLS 1.0 で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTP/2 入門
Studying HTTP