先輩と覚える HTTP ステータスコード
gistfile1.md 先輩に学ぶ HTTP Status Code 超雑にまとめました。修正してください。 登場人物 アプリケーション先輩: いつも忙しい。横に広がるのが得意(デブじゃない)。 後輩: 頼んでばっかしで役に立たない。 サーバー先輩: アプリケーション先輩と仲がいい。Unix Socket でつながるくらい仲良し。 プロクシ先輩: アプリケーション先輩とかサーバー先輩と後輩の間を取り持って代わりに伝えたりしてくれる。たまに勝手にレスポンスを書き換える。 1xx 系 100 Continue 後輩「あ、先輩！お願いが！」 アプリケーション先輩「おー、聞いてやる。詳しく話せ」 101 Switching Protocols 後輩「せんぱーい、お願いなんですけどー」 アプリケーション先輩「ちょっと待て、お前 HTTP 1.0 で喋るな、 HTTP 1.1 か TLS 1.0 で
net/http: remove support for status code 418 I'm a Teapot · Issue #21326 · golang/go
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community. Pick a username Email Address Password Sign up for GitHub By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails. Already on GitHub? Sign in to your account
HTTP1.1のLocationヘッダは、絶対URLでないとRFC違反 | 月と燃素と、ひと匙の砂糖
さきゅばす２のバグ対処で知ったお話です。とりあえず、HTTPの基礎知識はあることを前提にします。 さきゅばす２では、公式動画のDLがどうしても出来ませんでした。こんなエラーが出ちゃうんです。 [E][ PyBridgeImpl] Python says: (略) HTTPError: HTTP Error 302: Found - Redirection to url '/watch/1339405721' is not allowed どうやらリダイレクションの段階で問題が発生してるみたいですねぇ。 HTTPでのリダイレクション とあるページにアクセスした時に他のページにジャンプしなおさせる「リダイレクション」ですが、このリダレクションはHTTPはレスポンスヘッダで301,302,303,307のレスポンスコードを返した上で、Locationヘッダを設定することで実現しています。 どこか
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
HTTP の新しいステータスコード 103 Early Hints | blog.jxck.io
Intro これは、 http2 Advent Calendar 2016 の 16 日目の記事である。 HTTP に新しいステータスコード 103 Early Hints が追加されようとしている。 HTTP/1.1 および HTTP2 双方と関わり、リソース配信の最適化に利用することができる。 いったい何のために必要なのか、どういうメリットが考えられるかを解説する。 HTTP2 Push の復習 まず HTTP2 の Push について復習する。 H2 Push は、簡単に言えば PUSH_PROMISE フレームを用いて、レスポンスよりも先に依存するリソースを返すための仕様である。 例えば /users のレスポンスは script.js と style.css をサブリソースとして含んでいるとする。 HTTP2 では SQL を発行して Users の一覧を取得している間に、先行し
Varyヘッダについてメモ - rougeref’s diary
ここ最近キャッシュコントロールのヘッダについて研究中。というよりキャッシュってどうやって見つけるんだろうってことでお勉強、実験中です。 Varyヘッダの働きかたについてちょっと誤解していたので忘れないうちにメモ。 Squidの文書によると、2.6あたりからVaryとEtagの両ヘッダをサポートしたとのこと。 で、その文書にはいままでURIだけをキーにしてキャッシュを作成していたが、VaryとEtagのサポートに伴い、これらヘッダ値＋URIでmd5ハッシュを作成してそれをキーにしたと。store.logに残るのがそのmd5値。store.logの5カラム目ですね。 1444184896.876 SWAPOUT 00 0000B6C0 D05226074A35B354673E44DE98357310 200 1444184891 -1 -1 text/html 143485/143485 GE
RESTful API設計におけるHTTPステータスコードの指針 - Qiita
RESTful APIを設計した際のステータスコードの指針です。 メソッド別 GET 成功した場合 200 OK：最も一般的 304 Not Modified：条件付きGETでキャッシュを使わせたい場合 POST 成功した場合 201 Created 作成したリソースのURIを示すLocationヘッダを付けておく 議論 200 OKだとまずいのか？ 200 OKを応答する実装も多くあり、まずいというわけでもない 200 OKはPOST結果がキャッシュ可能、201 CreatedはPOST結果がキャッシュ不可能として分けてもいいが、そこまでする必要があるか？（POSTのキャッシュは一般的ではない） 204 No Contentだとまずいのか？ クライアントがPOST結果を事前に全て知っているわけではないのでNo Contentは不親切では？ 失敗した場合 409 Conflict：作成しよ
レイテンシに負けないプロトコルとして登場したHTTP/2～奥一穂氏による「HTTPとサーバ技術の最新動向」（前編）。Developers Summit 2016
私はWeb関連の基盤技術を20年くらいやっています。 最近の仕事としてはディー・エヌ・エーで「H2O」というWebサーバを開発していて、2016年2月に1.7.0をリリースしました。HTTP/2対応のWebサーバとしてはおそらく世界最速で洗練された実装だろうという評価をいただいています。 本日はサーバ技術をそもそもどういう評価軸でわれわれが見ているのか、HTTP/2の特長。そしてサーバプッシュとはなにか、HTTPS化はどれだけサーバ負荷が上がるのかについてのわれわれの見解。Webサーバ内でのスクリプト実行がどう変わってきているのか、といった話をしていきます。 サーバ技術の評価軸 サーバ技術の評価軸をどう考えているかですが、大きく分けて4つの項目で考えています。 サーバ負荷 転送データ量 応答性 設定・運用コスト まず「サーバ負荷」です。小規模なWebサイトではサーバ負荷はそれほど問題にはな
google-http-java-client 入門 - ひだまりソケットは壊れない
Java で HTTP 通信するときのクライアントライブラリを何にするかいつも悩むのですが、最近 google-http-java-client が気になってたのでちょっと使ってみました。 汎用的に HTTP 通信ができればよい、というような用途にはちょうど良さそうです。 数年前からベータ版や RC 版としては存在していましたが、正式にリリースされたのは今年のようです。 google-http-java-client について プロジェクトホーム: google-http-java-client - Google HTTP Client Library for Java - Google Project Hosting Google によって書かれた Java の HTTP クライアントライブラリです。 HTTP トランスポートの抽象化がされており、実際の HTTP 通信を行う低層のライブ
なぜ html の form は PUT / DELETE をサポートしないのか？ - Block Rockin’ Codes
注意 内容については一切保証しません。 ここでは、主に W3C ML での議論や各種仕様などに基づいて書いています。 ここに書かれていることが正しいかどうかは、自身で判断して下さい。 事実としておかしいところなどは、コメントでどんどん指摘して下さい。遠慮はいりません。 ただし、このエントリでは「form が PUT/DELETE をサポートするべきかどうか？」の議論はしません。 「REST の是非」や「PUT/DELETE の意義」についても議論する気はありません。 ここでやっているのは、あくまでもどういった議論の末現状があるのかの調査です。 そうした意見がある場合は、 W3C などに投稿するのが最も有益だと思います。 History 2014/03/29: 公開 2014/03/29: XForm と XHTML の関係を明確化(thanx koichik) 2014/03/29: HT
新たなHTTPステータスコード「308」とは？
By Eva Ekeblad ネットでさまざまなウェブサイトをめぐっていると、「404 Not Found」や「503 Service Unavailable」などの表示を目にしたことがある人も多いはず。この3桁の数字とメッセージの組み合わせは「HTTPステータスコード」と呼ばれ、インターネット技術の最も基本的な仕組みの一部です。1990年代初めに最初の骨組みが作られた仕組みですが、新たに「308 Permanent Redirect(恒久的リダイレクト)」というコードが追加されようとしています。 Pushing the Web Forward with HTTP/308 - IEInternals - Site Home - MSDN Blogs http://blogs.msdn.com/b/ieinternals/archive/2012/03/29/http-308-permane
Ruby の http ライブラリの通信を表示する http-dump を作った - 2nd life (移転しました)
Ruby 上で http を叩いた通信見たい時に、毎回同じ事をやってるので抽象化して http-dump というライブラリを作った。 https://github.com/hotchpotch/http-dump $ gem install http-dump require 'net/http' require 'uri' require 'http-dump' HTTPDump.dump { Net::HTTP.get(URI('http://example.com')) } と http でやりとりしてるコードを block で囲むと、以下のように出力される。 > GET http://example.com/ with headers {'Accept'=>'*/*', 'Accept-Encoding'=>'gzip;q=1.0,deflate;q=0.6,identity;q=
FacebookがSPDYを始めました！ - ぼちぼち日記
1. SPDYが熱いです！ ちょうど先週末CROSS2013の 次世代Webセッション(プロトコル編) にパネラーとして参加させていただきました。 次世代Webの鍵となるWebSocket・SPDY・HTTP/2.0について熱い話ができとても満足しています。会場は満員で皆さんがとても興味を持って聞いていただいているのも十分感じることができました。 参加していただいた方、本当にありがとうございました。 2. LINEがSPDYを使っている セッションでは、つい最近 LINE が SPDY を使っているという発表( http://tech.naver.jp/blog/?p=2381 )について紹介し、その有用性についていくつかコメントをしました。 SPDYは、 Google が2011年より2年近くほとんどのGoogleサービスで実運用していますが、Google以外で世界的にメジャーな大規模の
Webはインターネットになった - naoyaのはてなダイアリー
先週金曜日にエンジニアサポートCROSS2013に行ってきた。目当ては @Jxck_ さんホストによる次世代Webセッション。セッション自体は前後半に分かれていて 前半はプロトコル編。SPDY (wikipedia) や HTTP/2.0 の動向やその課題点など 後半はアーキテクチャ編。プロトコルが変わった上で、その上で動くソフトウェアのアーキテクチャが云々 という内容でした。前半がより技術寄り、後半はテーマ的にもより広範の話題を扱うという感じでどちらも面白かった。 CROSS 2013レポート(2) - mad-pの日記 こちらに細かいログがあります。 話の前提になる SPDY や HTTP/2.0 周りの昨今については 【HTTP 2.0の最新動向】 第1回：HTTP/2.0の策定、ついに始まる - INTERNET Watch Watch 【HTTP 2.0の最新動向】 第2回：HT
どぶお/開発しよう！/git-1 Smart HTTPとgitweb - BioKids Wiki
gitの環境を整えてみた 最近、バージョン管理システムとして流行のgitを使う環境を整えてみましたので記録。 GitLab 2.0をインストールした記録 -- git-2 GitLabをインストールする リモートリポジトリ 職場からも自宅からもリポジトリにアクセスできるようにしたかったので、リモートリポジトリを作成しました。 git + apache2/Smart HTTP 職場のファイアウォールがきつく、HTTPおよびHTTPSしか使えないのでHTTPアクセスを確保することにしました。以前はWebDAVがよく使われていたようですが、その方法だと速度が遅いそうな。それを解決するために用意されたのがSmart HTTPとのことです(たぶん)。 Smart HTTP Transport -- http://progit.org/2010/03/04/smart-http.html
次世代規格 HTTP2.0 のファーストドラフト公開 - Block Rockin’ Codes
intro 少し経って、去る11月28日に、HTTP プロトコルの次期規格となる HTTP2.0 のドラフト、 draft-ietf-httpbis-http2-00 が、IETF の httpbis ワーキンググループで公開されました。 このドラフトは Google から提案された仕様である SPDY が採用されています。 HTTP1.1 からのアップデート HTTP1.1 の RFC が提出されたのは 1999 年で、 13 年経った今年 2012年8月 に、 HTTP の仕様を議論する httpbis というワーキンググループが、 HTTP1.1 のアップデート版になる仕様、 HTTP2.0 の策定を開始しました。 これは、 HTTP1.1 の仕様策定がある程度落ち着いてきたこと、次期仕様を考える良い時期であること、 そしてなによりも、 Web の使われ方が大きく変わり、 求められて
先輩と覚える HTTP ステータスコード
gistfile1.md 先輩に学ぶ HTTP Status Code 超雑にまとめました。修正してください。 登場人物 アプリケーション先輩: いつも忙しい。横に広がるのが得意(デブじゃない)。 後輩: 頼んでばっかしで役に立たない。 サーバー先輩: アプリケーション先輩と仲がいい。Unix Socket でつながるくらい仲良し。 プロクシ先輩: アプリケーション先輩とかサーバー先輩と後輩の間を取り持って代わりに伝えたりしてくれる。たまに勝手にレスポンスを書き換える。 1xx 系 100 Continue 後輩「あ、先輩！お願いが！」 アプリケーション先輩「おー、聞いてやる。詳しく話せ」 101 Switching Protocols 後輩「せんぱーい、お願いなんですけどー」 アプリケーション先輩「ちょっと待て、お前 HTTP 1.0 で喋るな、 HTTP 1.1 か TLS 1.0 で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://clojure-liberator.github.io/liberator/assets/img/decision-graph.svg
なぜ html の form は PUT / DELETE をサポートしないのか？
Git - Blog Moved
