QUIC標準化動向 〜2017/7QUICの標準化動向を日本語で解説。HTTP/2勉強会発表資料(2017/08/23) https://http2study.connpass.com/event/63998/
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 の一覧を取得している間に、先行し
最近、httpstat なるものが流行っているらしい - tellme.tokyo
github.com おそらく先行実装は python で書かれたこれです。 curl にはウェブサイトの応答時間を計測する機能が搭載されており、このツールではそれを利用して出力結果をグラフィカルに表示させています。単なる curl のラッパーのようなツールなのですが、見た目がリッチになるのに加えて、単一ファイルで実行でき python のバージョンに影響されないような工夫がされているのが、受けているポイントのような気がします。 このツールを見たとき「Go で書いてみるの良さそう！（この手のツールで単一バイナリになるのは嬉しいですよね）」と思い、休憩時間やお昼休みなどにちまちま書いていたら、二日前に先を越されてしまいました（そりゃそうですよね。なんでもスピードが大事だと痛感）。 github.com また、ついこの間まで 800 Stars くらいだったのですが、ここ1週間で爆発的に伸びて
レイテンシに負けないプロトコルとして登場したHTTP/2～奥一穂氏による「HTTPとサーバ技術の最新動向」（前編）。Developers Summit 2016
私はWeb関連の基盤技術を20年くらいやっています。 最近の仕事としてはディー・エヌ・エーで「H2O」というWebサーバを開発していて、2016年2月に1.7.0をリリースしました。HTTP/2対応のWebサーバとしてはおそらく世界最速で洗練された実装だろうという評価をいただいています。 本日はサーバ技術をそもそもどういう評価軸でわれわれが見ているのか、HTTP/2の特長。そしてサーバプッシュとはなにか、HTTPS化はどれだけサーバ負荷が上がるのかについてのわれわれの見解。Webサーバ内でのスクリプト実行がどう変わってきているのか、といった話をしていきます。 サーバ技術の評価軸 サーバ技術の評価軸をどう考えているかですが、大きく分けて4つの項目で考えています。 サーバ負荷 転送データ量 応答性 設定・運用コスト まず「サーバ負荷」です。小規模なWebサイトではサーバ負荷はそれほど問題にはな
[Studying HTTP] HTTP Header Fields
この頁では、HTTPヘッダとは何かについて、またHTTP/1.1仕様書などで定義されているHTTPヘッダのうち代表的なものを解説します。 HTTPヘッダとは HTTP/1.1ヘッダ Accept Accept-Charset Accept-Language Accept-Range Age Allow Authorization Cache-Control Connection Content-Language Content-Length Content-Location Content-MD5 Content-Range Content-Type Date Expect Expires From Host If-Modified-Since If-Range If-Unmodified-Since Last-Modified Location Max-Forwards Pragma R
2015年Webサーバアーキテクチャ序論 - ゆううきブログ
2023年03月31日追記：この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We
HTTPのパケットを確認したり、書き換える事が出来るWeb Debugging Proxy「Fiddler」の勉強会に行って来ました - 強火で進め
Fiddler の勉強会に行って来ました。 Fiddler は HTTP の通信データを観たり、書き換えたりする事が出来るツールです。 イベントページ はじめての Fiddler reloaded | Peatix http://peatix.com/event/55312?utm_campaign=recommend&utm_medium=email&utm_source=55312&utm_content=7893 資料ページ はじめての Fiddler http://www.hebikuzure.com/fiddler/ Fiddler Scriptデモ http://www.slideshare.net/hagurese/fiddler-script-38509440 書籍 実践 Fiddler 作者: Eric Lawrence,日本マイクロソフト株式会社エバンジェリスト物江修,
レスポンシブウェブデザインへの変更時には302リダイレクトを使う、301ではない from #SMX Advanced 2014
レスポンシブウェブデザインまたは動的配信への変更にともない、モバイル向けサイト用に割り当てていた別URLを、PC向けサイトと統一したURLに変更する場合は302リダイレクトを利用します。 301リダイレクトではありません。 ドキュメントどおり302が正しい Googleは、スマートフォン向けサイトの移転の注意事項を解説したドキュメントを先日公開しました。 そのなかで、次のように説明しています。 サーバー サイドの 302 HTTP リダイレクトおよび Cache-Control: private ヘッダーを使って別個のスマートフォン向け URL をデスクトップ向け URL にリダイレクトします ※強調は僕による これを読んだとき、「301じゃないのか？ 」と僕は疑問に思いました。 同じ疑問を抱いたのは、きっと僕だけではないはずです。 そこで、GoogleのMaile Ohye（マイリー・オ
ボーイフレンドを直す方法 あるいは賢いjQuery.Deferredの使い方 - mizchi's blog
問題 モバイルは回線が不安定なので、ロードの失敗が頻繁に起こります。 開発時は高速なwifi環境で開発しているので、リリース間近になって帯域を圧迫していることに気づいたりします。 解決方法 画像を先読みします var preload = function(src){ var d = $.Deferred(); var img = new Image; img.src= src; img.onload = d.resolve img.onerror = d.reject return d.promise(); }; 何をやっているかというと、空のimgタグをつくってそこに画像を読み込みます。その過程でブラウザキャッシュに画像が保存されます。正確に言うとこの時点ではどこにも紐付いていないのでGC対象ですが、その後すぐDOMに画像をはるなら問題ありません。 並列で先読みする(速い・不安定) va
REST における PUT メソッドと POST メソッドの違い - 星一の日記
最近 REST に関する本を読んでいます。統一された少ないルールで、さまざまな Web アプリケーションを表現できるというのは、妄想が膨らんでワクワクしますね。学んだことをメモがてらに書きます。 RESTful Webサービス 作者: Leonard Richardson,Sam Ruby,山本陽平,株式会社クイープ出版社/メーカー: オライリー・ジャパン発売日: 2007/12/21メディア: 単行本購入: 25人 クリック: 842回この商品を含むブログ (168件) を見る PUT も POST も似た役割をもつメソッドです。両方ともリソースの新規作成または更新を行います。この二つのメソッドは何が異なり、どのように使い分けるべきなのでしょうか。 リソースの新規作成 まずリソースの新規作成について。 PUT は URI が指し示すリソースを直接作成することを、サーバーに要求します。たと
RESTful Web アプリの設計レビューの話
1. RESTful Web アプリの 設計レビューの話 和田 卓人 (a.k.a id:t-wada or @t_wada) July 23, 2012 @ sendagaya.rb 3. 自己紹介 名前: 和田 卓人 (わだ たくと) ブログ: http://d.hatena.ne.jp/t-wada メール: takuto.wada@gmail.com Twitter: http://twitter.com/t_wada タワーズ･クエスト株式会社 取締役社長 4. 私と REST (input) • WEB+DB PRESS vol.32「REST アーキテクチャスタイル入門」 • はてぶ設計議論 • DHH の RubyKaigi 2006 Keynote • WEB+DB PRESS vol.38∼「REST レシピ」 • 『RESTful Web Service』
HTTPリクエストの圧縮をサポートする - ただのにっき(2013-09-18)
■ HTTPリクエストの圧縮をサポートする HTTPクライアントから大きなデータをPOSTするときに圧縮可能ならそうして欲しい場合があって(もちろんブラウザはそんなことしてくれないので専用クライアントを使う前提)、サーバアプリは圧縮・未圧縮の状況にかかわりなく書きたいので、その部分だけRackミドルウェアにしてみた。ちなみにリクエストではなくてレスポンスなら普通の話なので何も考えずにRack::Deflaterを使えば良い。 最初、Rackでリクエストのbodyを操作する方法がわからなくてTwitterでつぶやいたら@moroが教えてくれたので解決。いつもいつも助かります(^^; こんな感じで使える: require 'rack/request_decompressor' use Rack::RequestDecompressor クライアントはContent-Encodingヘッダを追加
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GraphQL対REST - 考慮すべき点
HTTP/2の課題と将来について、YAPC Hokkaidoで話してきた
ウェブを速くするためにDeNAがやっていること - HTTP/2と、さらにその先
URLエンコード・デコード｜日本語URLをサクッと変換 | すぐに使える便利なWEBツール | Tech-Unlimited
https://www.eventhelix.com/RealtimeMantra/Networking/
なぜ html の form は PUT / DELETE をサポートしないのか？
Webアプリのデバッグに最適。HTTPに特化したネットワークキャプチャーツール「Fiddler」NOT SUPPORTED
httpbin.org