新しいHTTPメソッド、QUERYメソッドの仕様 - ASnoKaze blog
新しいHTTPメソッドを定義する「The HTTP QUERY Method」という提案仕様が議論されています。 もともとは、SEARCHメソッドという呼び名が候補としてあげられていましたが、長い議論ののち、一旦QUERYと呼ぶ方向となっております。最終的なFixについては、この draft 02の公開とともに改めてコンセンサスを求めた後に行われます。 QUERYメソッド 「GETリクエストにボディを付けたいという」という質問は長らく有りました。しかし、GETやHEADリクエストでボディをつけることは非推奨となっています (参考URL)。 そのような要望のなかで、リクエストでボディを含められる冪等性の保証された新しいHTTPメソッドが検討されました。それがQUERYメソッドです。冪等性があるため、ブラウザやProxyは自動でリトライすることができます。(なお、POSTはセマンティクス上冪等
HTTP/3の基盤となる「QUICプロトコル」の標準化プロセスが完了、IETFの「RFC 9000」として
HTTP/3の基盤となる「QUICプロトコル」の標準化プロセスが完了、IETFの「RFC 9000」として 現在標準化が進められている新たなHTTPである「HTTP/3」のトランスポート層プロトコルとなる予定の新しい通信プロトコル「QUIC」が、インターネットで用いられる通信プロトコルなどの標準化を行う団体のIETF（Internete Engineering Task Force）により「RFC 9000」として策定を完了、新たなインターネット標準になったことが明らかになりました。 QUIC is now RFC 9000 | Fastly QUIC is RFC 9000 | daniel.haxx.se QUICはもともとHTTPをより高速化するためにGoogleが開発し、その後IETFで標準化が進められてきました。 QUICはまずは次世代のHTTPであるHTTP/3のトランスポート
http-live-simulator - レスポンスの遅延が体験できるHTTPサーバ
開発時には気付きづらく、リリースした後に実際のユーザ環境で試してはじめて分かることはたくさんあります。例えばネットワーク環境です。モバイル通信は予想よりも遅かったり、負荷によってサーバのレスポンスが低下したりします。 http-live-simulatorは開発用のHTTPサーバですが、レスポンスがランダムに遅延するという特徴を持っています。 http-live-simulatorの使い方 インストールはnpmで行います。 npm install -g http-live-simulator 実行すると 8080番ポートでサーバが立ち上がります。 $ http-live http-live-simulatorはアクセスごとに200〜500msの遅延が生じます。単純に速度が遅くなるだけではないので、ライブラリやリソースの読み込み状態によって表示に影響が出るのが確認できるかも知れません。こうし
相手のサーバにHTTP(S)で接続できるかどうかを確認するときにリトライしながらやりたいんですけどって時 - その手の平は尻もつかめるさ
例えばCIでテストのためのストレージのコンテナを上げる際，そのストレージが上がりきるまで待たなければテストには使えないわけですが「上がりきるまで何秒待てばよいのか」というのは一概に決められるものではありません． そうした際，実際にストレージに対してHTTP(S)のリクエストを投げてみて，繋がったら「上がりきった」とみなして処理を次に進めるというようなことがよく書かれます．そういった要件を満たす為には接続に失敗したらリトライをしつつ一定回数試行するという処理を書かなくてはなりません． つまりはそういう話です． wgetの場合 retry-connrefused tries waitretry を利用すると出来る． retry-connrefused が無いと connection refusedに対応できずにリトライが不可能となるので，今回のような要件を満足するためには付ける必要があります．
検証！HTTP/2 - HTTP/2はどうしてコネクション一つで通信できるのか：ITpro
HTTP/2ではレスポンスが返ってくる前にリクエストを重ねて発行できるようにするため、どのレスポンスがどのリクエストと関連付けられているかを管理する仕組みが必要となる。 仮想パイプ「ストリーム」 そのためにHTTP/2では、「ストリーム」と呼ぶ仮想的なパイプを用意する。これがHTTP/1.1におけるコネクションに相当する（図6）。具体的には「ストリームID」という識別子が使われる。同一のストリームIDであれば、関連する一連のやり取りとして識別できるというわけだ。 HTTP/2では順不同でリクエスト－レスポンスが流れる。このため、リクエストとレスポンスを関連付ける仕組みが必要だ。そのために「ストリーム」という考え方が導入された。1対のリクエスト－レスポンスを表現する仮想的な通信経路が「ストリーム」である。ストリームの間を、複数種類のフレームがやり取りされる。 このストリームの上を複数の「フレ
HTTP/2に対応したウェブサーバーを簡単に構築！Dockerfileでオリジナルの環境を構築する手順について - ICS MEDIA
DockerfileをビルドしてDockerイメージを作成する Dockerfileとnginx.confの準備ができたら、Dockerfileのあるフォルダーに移動しdocker buildコマンドでイメージの作成を行います。 docker build -t icsmedia/nginx-http2 . -tオプションでは、生成するDockerイメージの名前を指定します。設定しない場合は、自動的に適当な名前で生成されます。.の箇所にはDockerfileが配置されているディレクトリを指定します。Dockerfileの配置されているフォルダーにいる場合は.と指定します。 実行すると数秒ほどでDockerイメージの作成が完了します。docker imagesコマンドを使って以下の通りDockerイメージが作成されていることを確認します。 $ docker images REPOSITORY
Big Sky :: golang の http.Client を速くする
« Windows からも ssh でリモートコマンド実行したい、それ golang で出来るよ | Main | Re: Go でシングルバイナリな Web アプリを開発しているときに webpack --watch をうまいところやる » この記事には幾らか正しくない部分がありました。後で訂正していきますが、ひとまず shogo82148 さんの解説記事も確認下さい。 http.Client はリクエスト毎に名前を引くので連続したアクセスはあまり速くない。 Goのhttp.Clientで名前解決結果cacheする楽な方法ないかな — fujiwara (@fujiwara) December 7, 2016 Go 1.8 からは Resolver が提供されるので、自前で簡単に名前引きのキャッシュを実装出来る。 Go 1.9 だった様です。 Go 1.8 Release Notes -
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 の一覧を取得している間に、先行し
golang の httptest パッケージを使う - at kaneshin
この記事は Go Advent Calendar 2016 - Qiita の2日目の記事です。 Golang については書きたいことがたくさんあるので、Go Advent Calendar 2016 その４が出てきても良いのではと思っている次第です。（空いていればいつでも書きます） さて、今回、この記事では Golang で書かれた Web アプリケーションのリクエストのユニットテストについて解説しようと思います。 github.com 1. Testing HTTP Handler 検証のために、ただ単に "pong" を返却する pingHandler と、URLクエリから値を取得してそのまま返却する echoHandler の2つを定義します。 ー pingHandler // pingHandler returns just "pong" string. func pingHan
最近、httpstat なるものが流行っているらしい - tellme.tokyo
github.com おそらく先行実装は python で書かれたこれです。 curl にはウェブサイトの応答時間を計測する機能が搭載されており、このツールではそれを利用して出力結果をグラフィカルに表示させています。単なる curl のラッパーのようなツールなのですが、見た目がリッチになるのに加えて、単一ファイルで実行でき python のバージョンに影響されないような工夫がされているのが、受けているポイントのような気がします。 このツールを見たとき「Go で書いてみるの良さそう！（この手のツールで単一バイナリになるのは嬉しいですよね）」と思い、休憩時間やお昼休みなどにちまちま書いていたら、二日前に先を越されてしまいました（そりゃそうですよね。なんでもスピードが大事だと痛感）。 github.com また、ついこの間まで 800 Stars くらいだったのですが、ここ1週間で爆発的に伸びて
ncatで遊んでみる - 超ウィザード級ハッカーのたのしみ
ncatという超便利コマンドを恥ずかしながらいままで知らなかった。HTTPプロトコルを学ぶには最適なおもちゃだ。 www.example.com の 80番ポートに、 / を GET するという HTTP リクエストを投げてみる。 fjk@x240:~$ ncat www.example.com 80 << END GET / HTTP/1.1 Host: www.example.com END すると、以下のような HTTP レスポンスが返ってくる。200番のステータスコードが帰ってきているので、リクエストはうまいこといったようだ。いろいろヘッダーフィールドについているが、こう見ると HTTP プロトコルはテキストを送って返すだけという非常に単純なプロトコルなことが分かる。 HTTP/1.1 200 OK Accept-Ranges: bytes Cache-Control: max-a
HTTPキャッシュ。なぜ嫌われるのか。 - それマグで！
忌み嫌われるキャッシュたち。 キャッシュはどうやら、世間では嫌われ者のようです。 ScrenCaptured_2016-03-05_0.54.33 どうして、そんなにキャッシュされるのがイヤなんだろうか。 そもそもキャッシュってなんだっけ？ キャッシュとは、更新されていないコンテンツ（画像、CSS、JS、HTML、DNS結果など）を何度も何度も取得行かずに済むように、クライアントPC側で保存し再利用する仕組み。 つまり、転送量の節約。無駄な転送を控える。非常にエコな仕組みであります。 HTTPのエコ。HTTPはエコなプロトコルだったはず。 3つのR です。 Reduce Reuse Remix 。複数のファイルをそれぞれ、別途管理して１つのページとして構成(Remix)する仕組みです。 ブラウザのキャッシュを利用するメリット 通信料の節約、画面表示の高速化、戻るボタン対応など。 ブラウザは
HTTPとサーバ技術の最新動向
デブサミ2016登壇資料。サーバ技術の評価軸、HTTP/2、サーバプッシュ、HTTPS化の負荷、Brotli、サーバ内スクリプティングを俯瞰Read less
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
Webサイトを「HTTP」から「HTTPS」へ切り替える際に行う一連の作業をまとめました｜今村だけがよくわかるブログ
Googleが「HTTPS everywhere」を提唱していることなどが影響して、HTTPSで通信できるようにWebサイト全体を独自ドメインに対してSSL/TLSによる暗号化を行い、運用をスタートしている様子がちらほら私の周りには増えてきました。 Google ではさらにもう一歩踏み込んで、数か月前の Google I/O では、「HTTPS everywhere」をウェブで提唱しました。 ユーザーがもっと安全にサイトを閲覧できるよう、すべてのサイト所有者の皆様に HTTP から HTTPS への切り替えをおすすめしたいと考えています。 （Google ウェブマスター向け公式ブログ: HTTPS をランキング シグナルに使用しますより） 私はしばらく動向を伺っていましたが「Webサイト全体をHTTPSへ切り替える流れは今後はより加速すると考えてもいい」と判断をし、このブログも全体をHTT
セキュリティ監査で文句を言われないHTTPステータスコードの使い分け - Qiita
最近はハンドリングしくてもいいや的な、入力改ざんで発生するバリデーションエラーをそのまま500のHTTPステータスで返すと、攻撃者が「なんか攻撃成功しちゃいそう」って思っちゃうとかなんとかで、監査的なところから「500はやめろ」って言われることがあります。 一理ある ということで、安易に500を返さない方法を考えてみます。 HTTPステータスコードにあまり馴染みのない方は、こちら…ではなく、こちらをまず読んでください。 HTTPステータスコードの使い分け基礎 400 まず、ユーザの入力値、データの状態によってエラーになるケースは 400 Bad Request とします。エラーメッセージを表示して再入力を促すHTMLページを返す、一般的な入力エラー系の遷移は200 OKを返しても、実用上問題はないかと思います。 ユーザの操作が原因で、サーバ処理がエラーになった場合も400で扱うのはおかしい
ScalaのHTTPインターフェース http4s 超入門
What’s http4s# RackやWSGIのScala版といったところ。公式サイトの説明も次のように書いてある。 http4s is a minimal, idiomatic Scala interface for HTTP. http4s is Scala’s answer to Ruby’s Rack, Python’s WSGI, Haskell’s WAI, and Java’s Servlets. まだまだ開発途中でドキュメントなどはあまり整備されていなくて、まともに使おうと思ったらソースコードを読む必要が出てきそう。次期Scalatraのバックエンドになるとかならないとか噂されているけどはてさて？もしかしたらAkkaやFinagleに押されて流行らずに終わる可能性もある。 ちなみにscalaz-streamが使われている。 Install# 最小構成で使う場合は http
HTTP のステータスコードを簡単に調べる - tellme.tokyo
HTTPステータスコードは、HTTPにおいてWebサーバからのレスポンスの意味を表現する3桁の数字からなるコードで、RFC 2616、RFC 7231等によって定められている。via HTTPステータスコード - Wikipedia 403とか404はよく目にもするので覚えていますが、300番台は？500番台は？とかとなると思い出せないことが多いです。いちいちググり直すのも手間。そんなときに、bash なりのシェルにてエイリアスとして登録しているハックを目にしました。 Jxck/dotfiles - GitHub このまま参考にさせてもらおう、と思ったのですがすべて登録するのもな、と思いコマンドで用意しました（番号が変わるものでもないので一度登録して変更することになる心配がないためエイリアスもいいと思います）。 b4b4r07/http_code - GitHub antigen で簡単に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
日本語 | HTTP/3 explained
HTTP/2入門
