TopicsPlaceHolder SectionTitlePlaceHolder TIME rest time current/total
GoogleがWebページ表示をスピードアップするプロトコル「SPDY」を発表した。テストではページ読み込み速度が最高で64%短縮できたとしている。 米Googleは11月12日、Web高速化を実現するためのアプリケーションレイヤープロトコル「SPDY」(スピーディーと発音する)を発表した。Googleが目指しているWeb高速化の一環で、HTTPをサポートし、Webページ表示の遅延時間を最小限に抑えるという。 SPDYに関するホワイトペーパーによると、同社はSPDYとともに、同プロトコル対応版のGoogle ChromeブラウザとオープンソースのWebサーバも開発した。これらのアプリケーションをHTTPとSPDYで稼働テストしたところ、ページ読み込み時間が最高で64%短縮できたという。 SPDYはセッションレイヤーをSSLの上に追加するので、単一のTCP接続で複数の相互データストリームを並
PSGI Implのsendfileについて PSGIなServerはsendfileを扱う時にどうするかのメモ。 $env->{'psgix.sendfile'}がセットされてれば、そこに書いてあるファイルパスを使う $res->[2]がGLOBだったら fileno($res->[2])して sendfile に fd を渡す $res->[2]->can('fileno') が生えてたら、$res->[2]->filenoからfdを取って使う $res->[2]->can('path') が生えてたら、$res->[2]->pathからファイルパスを取って使う 以上が、基本的なsendfileを使を行うときのパターンになる。 また、response headerにX-Sendfileなどの任意のヘッダが入っていて、その中にファイルパスが入っていれば、そのファイルパスを元にしてsend
Indeed, adding RAW_PATH_INFO could be a good idea, I also think that changing the PATH_INFO meaning could be worse than living with that bug. "So adding RAW_PATH_INFO, or REQUEST_URI which is currently not in the spec, to be undecoded might make more sense." Probably a bad idea to duplicate that kind of information in the environment. I don't understand what's the big deal about specifying PATH_IN
あるURLにPOSTでリクエストを発行した結果リダイレクトされたとき,そのリダイレクトのリクエストはGETなのでしょうか?POSTなのでしょうか? なんとなくGETっぽいけど… そこんとこどうなのか気になったので調べてみました.HTTPとかにはあんまりくわしくないので,おかしかったら指摘していただきたいです. 準備 リダイレクトが発生するレスポンスコードは以下の4つです. 301 MOVED PERMANENTLY 302 FOUND 303 SEE OTHER 307 TEMPORARY REDIRECT HTTP1.1のRFCやその解説によると,POSTリクエストした結果,レスポンスコードが302か307だった場合は,POSTでリダイレクトしたほうが良いようです.でも,ほとんどのクライアントはその決まりを守らずGETでリダイレクトしているとも書いてあります. そこで,Firefox/S
どういう場合に便利なんだっけ。てか HTTP プロトコルでいいじゃんみたいな。 たとえば httpd とアプリケーションサーバを分割するような環境なら、apache + fastcgi external server みたいな構成よりも、apache (mod_proxy + mod_proxy_balancer) + apache (mod_perl) とかのほうが柔軟だし。 あるいは、apache + fastcgi external server みたいなのを組むよりも、apache (mod_proxy + mod_proxy_balancer) + HTTP::Server::Simple (Net::Server::Prefork) でいいんじゃないかみたいな。 unix socket を動的に作成して通信、みたいたことをする場合でも、独自プロトコルな必要ってないんじゃないのか
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
December 17, 2003 Mark Pilgrim I wish I didn't need to write this article. My life would be much simpler if Atom could just use existing HTTP authentication, as-is. But it can't; I'm going to tell you why and then I'm going to tell you what we're doing instead. Let's back up. Atom, in case you missed it, is a new standard that uses XML over HTTP to publish and syndicate web-based content. It is in
2007年05月11日18:45 カテゴリiTech あなたのページを最速にする14の掟 人気Webサイトの管理人、必読。 紹介ページ: 14 rules for fast web pages (Skrentablog) PPTのスライド: http://www.web2expo.com/presentations/webex2007/souders_steve.ppt 実は、これらはYahoo!の"Chief Performance Yahoo!"(本当にそういう役職名)であるSteve Soudersによる以下のblog entriesをまとめたもの。 Performance Research, Part 1: What the 80/20 Rule Tells Us about Reducing HTTP Requests Performance Research, Part 2:
2007年04月17日22:30 カテゴリLightweight Languages CPAN - HTTP::Response::Encoding Released! HTTP-Response-Encoding を Release したのでお知らせします。 on CPAN (coming soon) http://www.dan.co.jp/~dankogai/cpan/HTTP-Response-Encoding-0.03.tar.gz どういうものかというと、こういうものです。 use LWP::UserAgent; use HTTP::Response::Encoding; my $ua = LWP::UserAgent->new(); my $res = $ua->get("http://www.example.com/"); warn $res->encoding; prin
2006年12月21日17:30 カテゴリSciTech HTTPサーバーのパイプライン対応 今回は、HTTPのパイプラインの話。 「RFC2616の同時接続数の規定」@水無月ばけらのえび日記 「HTTPの同時接続数はどうあるべきか? (slashdot.jp) 」というお話。誰も原文を引用していないのが悲しかったので、引いておきます。 スラッシュドット ジャパン | HTTPの同時接続数はどうあるべきか?-taka2さんのコメントそれなら、「同時接続」しなくても、結果が返ってくる前に次のリクエストを送出して「リクエスト送信」と「結果受信」を並行して行えるようになれば、スループットの向上は見込める。 それがパイプライン化 [mozilla-japan.org]で、同時接続するよりも効率が良い。パイプライン化の前に、HTTPで何が行われているのかを、実際に見てみよう。telnetコマンドがあ
Cookieの仕様は、Netscape Communications Corporation が、 http://wp.netscape.com/newsref/std/cookie_spec.html で公開しております。このドキュメントをfutomiが日本語化したものです。みなさまのCookieの理解に役立てれば幸いです。なお、緑色で記載された文章は、futomiが注釈として加筆したものです。また、一部、直訳ではなく、意訳した部分がございます。原文と表現がことなることがございますので、ご了承ください。 注意: この日本語訳は、futomiがCookieの理解を深めるために、自分なりに日本語にしたものです。本日本語訳には、翻訳上の誤りがある可能性があります。したがって、内容について一切保証をするものではありません。正確さを求める場合には、必ず原文を参照してください。当方は、この文書によっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く