Cache-Control の Immutable 拡張によるリロード時のキャッシュ最適化 | blog.jxck.io
Intro ブラウザはリロード時に、 max-age に満たないキャッシュを持っていても Conditional GET によってキャッシュの Validate (有効性の問い合わせ)を行う。 Cache-Control Extension として提案されている Immutable 拡張は、キャッシュが max-age 内であればリロード時もキャッシュヒットさせる拡張である。 このヘッダの効果と、本サイトへの適用について記す。 Cache-Control Cache-Control に max-age を指定することで、ブラウザにリソースをキャッシュさせることができる。 このキャッシュは max-age の期間内は fresh とみなされ、 fresh であればサーバへの問い合わせなく再利用される。 サーバへの問い合わせ(RTT)が無いため、事実上最速のリソース取得となる。 Reload
オリジン間リソース共有 (CORS) - HTTP | MDN
HTTP ガイド リソースと URI ウェブ上のリソースの識別 データ URL MIME タイプ入門 よくある MIME タイプ www 付きと www なしの URL の選択 HTTP ガイド HTTP の基本 HTTP の概要 HTTP の進化 HTTP メッセージ 典型的な HTTP セッション HTTP/1.x のコネクション管理 プロトコルのアップグレードの仕組み HTTP セキュリティ Content Security Policy (CSP) HTTP Strict Transport Security (HSTS) X-Content-Type-Options X-Frame-Options X-XSS-Protection サイトの安全化 HTTP Observatory HTTP アクセス制御 (CORS) HTTP 認証 HTTP キャッシュ HTTP の圧縮 HTT
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 の一覧を取得している間に、先行し
Prevent unnecessary network requests with the HTTP Cache | Articles | web.dev
Prevent unnecessary network requests with the HTTP Cache Stay organized with collections Save and categorize content based on your preferences. Fetching resources over the network is both slow and expensive: Large responses require many roundtrips between the browser and the server. Your page won't load until all of its critical resources have downloaded completely. If a person is accessing your s
HTTP/1.1 just got a major update.
The IETF just published several new RFCs that update HTTP/1.1: RFC 7230: Message Syntax and Routing RFC 7231: Semantics and Content RFC 7232: Conditional Requests RFC 7233: Range Request RFC 7234: Caching RFC 7235: Authentication RFC 7236: Authentication Scheme Registrations RFC 7237: Method Registrations RFC 7238: the 308 status code RFC 7239: Forwarded HTTP extension These documents make the ori
Androidの通信周りのコーディングについて
2012/03/14 に株式会社 PRO&BSC にて行った Android 研修の資料 #3 です。
HTTPで正しくキャッチボールをするには | Lab by engineering@dwango.jp
皆さんはキャッチボールは好きですか? 私はバスケットボールの方が好きです。 キャッチボールは、自分と相手双方がボールをうまくキャッチできるように投げる必要があります。これは、サーバーとクライアントの間でも同じで、クライアントから投げられたボール(リクエスト)をサーバーは正しく投げ返す(レスポンス)必要があります。 ここで、サーバーがボールをあさっての方向に投げたり、異常なスピードで投げ返すとどうなるでしょうか。おそらくクライアントはそのボールを取ろうとしますが、追いつけずにボールを落としたり、どこかにぶつけたりしてしまうでしょう。 今回は、HTTPについて、どうして正しくレスポンスを返さないといけないのかということについて、Rackを使用して解説していきます。 対象読者 Webアプリケーション開発に興味のある方、これから開発を行おうとしている方 Rackについて まず、今回使用するツール
FurlX::Coro を使ってみたかった - はちゅにっき
節電対応で休日が日・月になった hatyuki です。ということで、明日がおやすみ！ 「DB から引っ張ってきた 5,000 件くらいの URL が、全部 HTTP Status Code 200 を返してくるか調べたいんだけど。」 という、なさそうでやっぱない依頼をうけたのでささっと書いてみることに。 ぱっと思いついたのはこんな感じ。 use strict; use warnings; use Furl; use My::Util qw/ db /; use Test::More; my $furl = Furl->new; my $itr = db->search('tables'); while (my $row = $itr->next) { my $res = $furl->head($row->url); is $res->code, 200, $row->url; } don
WebAPIを駆使して東京電力使用状況メーターを作る！（Node.js版） - tokuhirom's blog
http://chalow.net/2011-04-02-1.html にかいてあるものを node.js にしてみた。 HTTPのリクエストには https://github.com/driverdan/node-XMLHttpRequest を使用。node.js の HTTP クライアントライブラリは Furl::HTTP とおなじぐらい低レベルなので、ラッパーをかませないととてもつかえない。 var sys = require('sys'); var XMLHttpRequest = require('xmlhttprequest').XMLHttpRequest; var APPID = 'APPID'; var URL = 'http://setsuden.yahooapis.jp/v1/Setsuden/latestPowerUsage?appid=' + APPID; va
Reverse HTTP - てきとうなメモ
Reverse HTTPが何やっているのかよくわからなかったのでメモ． Reverse HTTPって何 これ． http://www.reversehttp.net/index.html URLを要求してそこにサービスを構築できる アプリケーション開発者はhttp requestを処理してhttp responseを返すCGIのようなコードを書くだけ httpクライアントの仕組みを用いてhttpサーバを実装している 目的は？ webサービスを簡単に作って簡単に配置しようということかな 制限された環境でもwebサービスを実行可能 ブラウザ内JavaScriptでサービスを実行 global ipなしで実行可能 webhookを利用したい人はprivate ipしかもっていないマシンからGateway Service経由でサービスを公開できるので簡単とか． 仕組み 以下のようにGateway
にひりずむ::しんぷる - 初めての Furl
巷でとっても速くて便利だねこれってなってる HTTP Client であるところの Furl の簡単なつかい方を紹介します。 そもそも Furl は何かっていうと、perl には LWP っていう超高機能な HTTP Client があって、これがデファクトになってるんですね。 でも、それって結構昔からあって、かつ重厚長大なモジュール群なので結構遅いわけです。とくに CPU 使用率が高い。 そんなわけで、libcurl ぐらい速くて軽い HTTP Client があるといいよねってことで開発されたのが Furl です。 読み方は ふぁーる。 use strict; use warnings; use 5.0100; use Furl; my $furl = Furl->new(agent => 'Madoka-Magica/chu-2'); my $res = $furl->get('ht
5x performance - switching from LWP to Furl & Net::DNS::Lite
Recently I rewrote some of our code that used LWP::UserAgent to use Furl instead, and have been observing more than 5x increase in performance (the CPU time spent for each HTTP request in average has dropped 82%). The fact clearly shows that if you are having performance issues with LWP::UserAgent it is a good idea to switch to Furl. And here are my recommendations when doing so: use the low-leve
commandlinefuの APIアクセスに Furlが使えない理由を考える - Shohei Yoshida's Diary
HTTPの知識が皆無なのでなんとも言えないのですが、 気になったなのでに調べてみた。きっと送るヘッダが違うんだろうと いうことで、それについて調べてみます。 #!/usr/bin/env perl use strict; use warnings; use lib qw(../lib); use Furl; my $url = 'http://www.commandlinefu.com/commands/matching/ssh/c3No/json'; my $ua_furl = Furl->new(); my $res_furl = $ua_furl->get($url); unless ($res_furl->is_success) { die "Error : ", $res_furl->status_line, "\n"; } print "[Furl]\n", $res_furl
HTTP/1.1 における Keep-Alive と HEAD の関係性について - tokuhirom's blog
HTTP/1.1 においては、HEAD リクエストの場合には Message Body を送信してはならないということにはなっているのですが、現実的には、Message Body をおくりかえしてくるアホなサーバーがおおい。たとえば Plack では Plack::Middleware::Head を明示的に使用していない場合、普通にやると HEAD でも message body をかえしてしまうだろう。 というわけで、HEAD で Message Body をかえしてくれるサーバーがおおいのだが、Message Body をかえされてしまうと、Keep-Alive しているときにこまる。次のリクエストとまじる。 この問題にたいするよい解決策はないので、HEAD リクエストを送信した後には connection を close してしまうのが、現実的な解決策だとおもった。 現実的には、現
404 Blog Not Found:HTTPサーバーのパイプライン対応
2006年12月21日17:30 カテゴリSciTech HTTPサーバーのパイプライン対応 今回は、HTTPのパイプラインの話。 「RFC2616の同時接続数の規定」@水無月ばけらのえび日記 「HTTPの同時接続数はどうあるべきか? (slashdot.jp) 」というお話。誰も原文を引用していないのが悲しかったので、引いておきます。 スラッシュドット ジャパン | HTTPの同時接続数はどうあるべきか?-taka2さんのコメントそれなら、「同時接続」しなくても、結果が返ってくる前に次のリクエストを送出して「リクエスト送信」と「結果受信」を並行して行えるようになれば、スループットの向上は見込める。 それがパイプライン化 [mozilla-japan.org]で、同時接続するよりも効率が良い。パイプライン化の前に、HTTPで何が行われているのかを、実際に見てみよう。telnetコマンドがあ
HTTP/1.1 の chunked encoding を使った POST / PUT を避けるべき理由 - kazuhoのメモ置き場
通信相手のサーバが HTTP/1.1 対応と確認できるまでは 1.0 と互換性のない chunked encoding は使えないし でも確認が取れた接続を使い回す = HTTP/1.1 の持続的接続を使い回して POST / PUT するってことだけど、持続的接続のタイムアウト条件は、TCP 接続確立後初回のリクエストより厳しいし 従って、POST / PUT は、べき等性がないリクエストだから持続的接続には投げるのは避けた方が無難だし ということで、基本使うべきじゃない。という話をした (http://github.com/tokuhirom/p5-Furl/commit/67c3ea52a23542a44e58869d0bcebcb53becd34a)。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
VCRで外部APIとのやりとりを記録する - Qiita
httpbin.org
【HTTP2.0最新動向】SPDYからHTTP/2.0へ～HTTPbis WG Interim Meetingレポート 
GitHub - miyagawa/Plack: Moved to https://github.com/plack/Plack
