The complete guide to Go net/http timeouts
When writing an HTTP server or client in Go, timeouts are amongst the easiest and most subtle things to get wrong: there’s many to choose from, and a mistake can have no consequences for a long time, until the network glitches and the process hangs. HTTP is a complex multi-stage protocol, so there's no one-size fits all solution to timeouts. Think about a streaming endpoint versus a JSON API versu
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
「WebAPI 設計のベストプラクティス」に対する所感 - Qiita
「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日本語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTful API」は「当該記事」と表現します。 観点 当該記事では「○○とした方がよい」との意見に対してそうすべき理由が明らかになっていないか、もしくは表現が曖昧な場合が目立っていると感じました。設計は実装のようにプログラム言語仕様が制約を与えられないため、意図
Kazuho's Weblog: ウェブページの描画 (first-paint) までの時間を測定するツールを作った件、もしくはHTTP2時代のパフォーマンスチューニングの話
ウェブページの描画 (first-paint) までの時間を測定するツールを作った件、もしくはHTTP2時代のパフォーマンスチューニングの話 ウェブページの表示までにかかる時間をいかに短くするかってのは、儲かるウェブサイトを構築する上で避けて通れない、とても重要な要素です。 少し古いデータとしては、たとえば、ウェブページの表示が500ミリ秒遅くなると広告売上が1.2%低下するというBingの例なんかも知られているわけです。 「ウェブページの表示までにかかる時間」と言った場合、実際には以下のようないくつかのメトリックがあります。 イベント 意味
Go言語でGraceful Restartをする
とあるHTTPサーバをGolangで立てようって話になったんだけど、 止まると困るので無停止でサーバ再起動をしたい。 PerlにはServer::Starterという有名モジュールがあるんだけど、 Golangはどうなってるの？ってことで調べてみました。 2017-01-22追記: Go1.8以降でGraceful Shutdownがbuild-inになるので、この記事で紹介したライブラリは不要となりました。 詳しくはGo1.8のGraceful Shutdownとgo-gracedownの対応を参照。 gracefulじゃないバージョン Golangの標準ライブラリを使ってHTTPサーバを立ててみる例。 レスポンスが一瞬で終わってしまうとよくわからないので、sleepするhandlerを追加しておきます。 package main import ( "fmt" "log" "net/ht
なぜ今、新しいHTTPサーバが必要なのか - H2O について勉強会で話したこと
先月末の話になりますが、SAPジャパンさんを会場に開催されたデータ転送ミドルウェア勉強会で、私が中心になって開発しているHTTPサーバ「H2O」について話す機会をいただき、登壇してきました。 以下は当日使用したスライドです。なぜ今H2Oを開発しているのか、その背景にある現状認識と将来の方針について、日本語で説明してあるので、興味ある方はご覧ください。 発表の機会をくださった@repeatedlyさんと@frsyukiさん、会場を提供してくださったSAPジャパンさん、ありがとうございました。 H2Oの開発は順調に進んでおり、HTTP/2サーバプッシュへの対応も完了し、まもなく次のバージョンがリリースできるかと思います。今後ともよろしくお願いいたします。
H2O - making HTTP better
1. Copyright (C) 2015 DeNA Co.,Ltd. All Rights Reserved. H2O making HTTP better DeNA Co., Ltd. Kazuho Oku 1 2. Copyright (C) 2015 DeNA Co.,Ltd. All Rights Reserved. ⾃自⼰己紹介 n 奥 ⼀一穂（株式会社ディー・エヌ・エー CTO室） n これまでの仕事： ⁃ Palmscape / Xiino • 世界初のPalm OS⽤用本格的ウェブブラウザ ⁃ IPA未踏スーパークリエータ（Webアプリ開発環境） ⁃ Q4M, mycached 等 MySQL 拡張 ⁃ picohttpparser, Server::Starter, Starlet, … • Perl のWebアプ
プライバシーモードでもiPhoneでも追跡? エンジニアが知っておくべき「HSTS Super Cookies」 | DevelopersIO
プライバシーモードでもiPhoneでも追跡? エンジニアが知っておくべき「HSTS Super Cookies」 こんにちは、せーのです。 みなさんは数日前から軽く話題になっているクッキーについてご存知でしょうか。その名も「HSTS Super Cookies」と言います。このクッキーは通常のブラウザモードはもちろん、クッキーなどを残さない「プライバシーモード」果ては同一iCloudアカウントのiPhoneまで追跡できる、というではないですかなにそれこわい。 ということで今日はこの「HSTS Super Cookies」とは何者で、どういう仕組みでこうなっているのか、現時点での対応状況をご紹介します。 まずは見てください。 まずは百聞は一件に如かず、ということでこちらを御覧ください。 何か数字と文字が合わさったパスワード的なものが出てきていますでしょうか。これがいわゆる「HSTS Supe
HTTP/2から見えるTLS事情 - あどけない話
これは HTTP/2 アドベントカレンダー19日目の記事です。 この記事はたくさんの資料を読んだ上で書きましたが、間違いとか勘違いとかがあるかもしれません。もしあれば、指摘していただけると幸いです。 実質的に必須となったTLS HTTP/2は、HTTP/1.1と同じく、暗号化なし/ありのポートとして、80と443を使います。そのため、通信開始時にHTTP/1.1とHTTP/2をネゴシエーションするための仕組みが、HTTP/2で定められています。 このように仕様としては暗号化なしのHTTP/2が定義されていますが、Firefox や Chrome が TLS を要求するために、実質的は暗号化ありが必須となっています。これは、米国の監視プログラムPRISMに代表される広域監視(pervasive surveillance)に対抗するために、IETFがさまざまな通信にプライバシの強化を要求する方
HTTPパーサにおけるSSE4.2最適化の威力と注意点 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、サイボウズ・ラボの光成です。 PicoHTTPParserは@kazuhoさんたちが開発している高速なHTTPパーサです。 同じ作者によるHTTPサーバH2Oにも使われています。 11月4日の開発ブログによると、その時点でNode.jsなどに使われているhttp-parserの10倍程度の速度を誇るそうです（現在はhttp-parserも速度向上しその差は縮まりました。それでも4倍以上の差があるようです）。 該当ブログにはその高速化のためのノウハウが書かれていて大変興味深いです。ただIntel系CPUに搭載されているSIMD命令は用いられていませんでした。今回、@kazuhoさんと一緒に文字列処理専用のSSE4.2を用いることで1.7～1.9倍の高速化を達成しました（Improving Parser Performance using SSE Instructions (in
Making and Using HTTP Middleware
When you're building a web application there's probably some shared functionality that you want to run for many (or even all) HTTP requests. You might want to log every request, gzip every response, or check a cache before doing some expensive processing. One way of organising this shared functionality is to set it up as middleware – self-contained code which independently acts on a request before
sprintf を最大10倍以上高速化するプリプロセッサ「qrintf」を作った
最近H2OというHTTPサーバを書いているのですが、プロファイルを取ってみるとsprintfが結構な時間を食っていて不満に感じていました。実際、sprintfは数値や文字列をフォーマットするのに十徳ナイフ的に便利なので、HTTPサーバに限らず良く使われる（そしてCPU時間を消費しがちな）関数です。 では、sprintfを最適化すれば、様々なプログラムが より高速に動作するようになるのではないでしょうか。ということで作ったのが、qrintfです。 qrintfは、Cプリプロセッサのラッパーとしてソースコードに含まれるsprintfの呼出フォーマットを解析し、フォーマットにあわせたコードに書き換えることで、sprintfを高速化します。 たとえば、以下のようなIPv4アドレスを文字列化するコード片を sprintf( buf, "%d.%d.%d.%d", (addr >> 24) & 0xf
Http2.0 Guide 2013-08-14 #http2study
This document provides a summary of the history and status of HTTP/2.0. It discusses the origins and versions of SPDY, which served as the basis for HTTP/2.0. Key aspects of HTTP/2.0 covered include multiplexing, binary frames, header compression, server push, and implementations. Tools for developing and testing HTTP/2.0 applications are also mentioned.Read less
HerokuのAPIデザイン
Herokuが自ら実践しているAPIデザインガイドをGithubに公開した． “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて，ビジネスロジックに集中すること目的としている．Heroku特有なものではなく，一般にも十分適用できる知見となっている． 最近は，モバイル向けにAPIをつくることも多いため，勉強もかねて抄訳した．なお内容は，HTTP+JSONのAPIについて基本的な知識があることが前提となっている． 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと．例えば，“成功"を示すステータスコードは以下に従う． 200: GETやDELETE，PATCHリクエストが成功し，同時に処理が完了した場合 201: POSTリクエストが成功し，同時に処理が完了した場合 202: POSTやDELETE，PATCHリク
アプリケーション・サーバのセッションの保存先の話 - プログラマでありたい
Webシステムの方式設計をする際に、わりと悩むのがアプリケーション・サーバのセッション（session）の保存先です。アプリケーションサーバとは、TomcatやJBoss,IISやRuby on Railsなどで利用するUnicornやPassengerなどです。そもそもHTTPの基本仕様がステートレスな為、状態を保持する為にはどこかに状態を保持する必要があります。その解決策がセッションになります。そこでセッションの保存戦略を考える必要があるのですが、アプリケーションサーバやサイトの用途や性格、扱うデータの気密性・重要性によっても変わってきます。 それ以前にセッションの保存先のことの呼び方の定番が何かすら解らなかったりします。セッション・ストアとかセッション・ストレージとか、はたまたセッション・マネージャーとか。今回は、セッション・ストアで統一します。 主なセッションストアの種類と保存戦略
ウェブエンジニアのためのオンラインツールまとめ
The Web engineer's online toolboxというまとめ記事が便利そうだったので、実際に試しつつ抄訳してみました。(一部のコメントと体裁は変えています。) 目次 一覧 RequestBin httpリクエストを保存するエンドポイントを作ってくれる。 Create a RequestBin のボタンをクリックするとURLが表示されるので、そこをHTTPクライアントからたたくとRequestBin側にリクエスト内容が記録される。 ソースも公開されてるのでローカルで立ちあげることもできる。 githubのwebhookのhelpも参考にどうぞ。 Hurl httpリクエストを実行してくれる。パーマリンクも作ってくれるので、POSTリクエストもコピペで他の人と共有できる。 類似サービス: REST test test , Apigee console httpbin HTTP
プラスαなサーバ監視
ちわっす！インフラ担当の池田（@mikeda）です。 今日はサーバ監視周りの話です。 まずNaviPlusでは、サーバ監視にNagiosとMuninを使っています。 普通ですね！ 気をつけていることは、ちゃんとサービスも監視する（正常なHTTP応答、応答速度など）ということでしょうか。 まぁこのへんは今日の本題ではないので別の機会に話します。 システム運用してると、こんな情報も見たいなーというのが出てきます。 例えば、今回紹介するのはこんなのです。 障害発生時（例えば昨日のXX時XX分）の全サーバのプロセスリスト 全サーバのリソース使用状況のザックリとしたレポート あのDBでXX時ごろに流れてたクエリはどんなのか 去年のセール時のアクセス数やサーバ負荷の状況が見たい 本番サーバでtmuxを起動しっぱなしの人がいないか こういう既存ツール（うちだとNagios/Munin）にマッチしないもの
HTTPリクエストを減らすために【序章】HTTPリクエストは甘え - MOL
このシリーズはHTTPリクエストの理解を通じてWebパフォーマンスの重要性について考える5章構成になっている。 【序章】HTTPリクエストは甘え 【CSS Sprite編】スプライト地獄からの解放 【WebFont編】ドラッグ＆ドロップしてコマンド叩いてウェーイ 【DataURI編】遅延ロードでレンダリングブロックを回避 【終章】我々には1000msの猶予しか残されていない 1日目は、HTTPリクエストの概要について説明する。 例えに、私のポートフォリオページ（t32k.me）が表示されるまでの流れを見ていく。まず、検索からでも方法はなんでもよいが、ブラウザのURLバーにt32k.meと打ち込んでアクセスする。そのページを見にいくということは、つまりt32k.meに対してHTTPスキームでリクエストするということを意味している。 クライアントであるブラウザは入力されたURLを判断して、リソ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
H2O - the optimized HTTP server
http://sassembla.github.io/Public/2014:05:02%2023-21-31/2014:05:02%2023-21-31.html
