タグ

httpに関するikasam_aのブックマーク (16)

  • なぜHTTPSはHTTPより速いのか

    先週、httpvshttps.com というウェブサイトが公開されました。このウェブサイトでは、HTTP と HTTPS を用いてアクセスした場合のウェブページのダウンロード完了までにかかる時間の比較ができるのですが、多くの環境で HTTPS の方が HTTP よりも高速なことに驚きの声が上がっていました。 HTTP が TCP 上で平文を送受信するのに対し、HTTPS は TCP 上で TLS (SSL) という暗号化技術を用いて通信を行います。ならば、TLS のオーバーヘッドのぶん HTTPS のほうが遅いはずだ、という予測に反する結果になったのですから、驚くのも無理はありません。 実は、この結果にはからくりがありました。 Google Chrome、Mozilla Firefox、最近のSafari注1は、Google が開発した通信プロトコル「SPDY」に対応しており、HTTPS

    なぜHTTPSはHTTPより速いのか
  • HTTP通信を含むモジュールのテスト #2 - Articles Advent Calendar 2011 Test

    はじめに こんにちは。ikasam_a です。 8日目に bayashi さんが [/articles/advent-calendar/2011/test/8:title=HTTP通信を含むモジュールのテスト] というエントリを書かれていますが、今日はその続編的な話をします。 フェイクとスタブ 前のエントリでは Test::Fake::HTTPD を使ってフェイクサーバを立ててテストする、という手法が紹介されています。これは テストダブル (Test Double) で言うところの Fake という概念で、"動作するけど手抜き" なサーバを用意して実際に HTTP 通信可能にするってわけです。これで実際のサービスに DoS することなくテストできるので、積極的に使いたいところです。 テストダブルとは何ぞや?という話は、別のエントリでしたいと思いますので、今日はさらっと流してください! この

    HTTP通信を含むモジュールのテスト #2 - Articles Advent Calendar 2011 Test
    ikasam_a
    ikasam_a 2011/12/16
    Test Track 16日分書いたよー。
  • HTTP通信を含むモジュールのテスト - Articles Advent Calendar 2011 Test

    こんにちは!こんばんは!寒いのがめっぽう苦手、bayashi です! きょうは、HTTP通信を伴うモジュールのテストについて書いてみます! サンプルモジュール WWW::Foo8 具体的に説明するために、WWW::Foo8 というモジュールを書きました! package WWW::Foo8; use strict; use warnings; our $VERSION = '0.01'; use Class::Accessor::Lite ( rw => [qw/agent error/], ); sub new { my ($class, %args) = @_; $args{agent} = _default_agent() unless $args{agent}; bless \%args, $class; } sub get { my ($self, $uri) = @_; my

    HTTP通信を含むモジュールのテスト - Articles Advent Calendar 2011 Test
  • L'eclat des jours(2006-10-28)

    _ NETアプリケーションにリモートオートメーションを付ける 必要がでてきて、ちょっと考えた。 たとえば、定期的に何かする静かなアプリケーション(UIと言えばタスクバーの通知領域にアイコンがあって、たまに「エラーになってるからログ見てくれ」とか吹き出しが出る程度のやつ)が今何してるか知りたいとする。 クライアントは、HTAとかだよな、やっぱり、と考える。 すると逆向きCOM Interopってのが候補に挙がる。 が、なんか違う気がする。大体、後からノートPCをHubに差し込んで調べるというようなこと考えると、危険極まりないDCOMの利用になってしまう。それは、最悪の場合に最悪の事態となる。 ではRemotingって……相変わらずVisual Studioのサポートないのか。却下だ。 Webサービス……「追加」からは選べないな。 で、System.Net.HttpListenerを使うことに

  • HTTPコンテンツ圧縮とPlack - blog.nomadscafe.jp

    「HTTPコンテンツ圧縮はどのレイヤーで行うのがいいか」で書いたりしましたが、高トラフィック環境では、サーバ間の通信量も問題となるため、ApplicationサーバでもHTTP圧縮をかけたほう良さげです。Plackには既にPlack::Middleware::DeflaterというApacheのmod_deflate相当のMiddlewareがあるのですが、ちょいちょい弄っていたりするのでその紹介。 その前に、HTTPコンテンツ圧縮のおさらいです。HTTP圧縮はリクエストのAccept-Encodingにgzipやdeflateがあった場合に、コンテンツをgzip、deflateなどで圧縮し、レスポンスのContent-Encodingヘッダに圧縮に用いた方式を表記することで実現されます。さらに、クライアントサーバ間にキャッシュサーバが存在した場合に、Accept-Encodingを送って

  • Plack::Test で HTTP クライアントのテストを書く方法 - Craftworks Tech Blog - Branch

    先日、WWW::Curl をラッピングした HTTP クライアントなモジュールを書いたのですが、テスト用に HTTP サーバーを用意しないといけないと思いつつ、他の HTTP クライアントがどのようにテストをしているか調べてみたところ、WWW::Curl は、 my $url = $ENV{CURL_TEST_URL} || "http://www.google.com"; などとしていて、LWP は Net::HTTPServer を使っているようでした。 ネットワークが繋がっていないとテストが出来ないのもなんですし、Net::HTTPServer 使ってサーバー書くのも面倒臭そうなので、来の用途とは違いますが、シンプルに書けそうな Plack::Test で書いてみることにしました。 use strict; use warnings; use Test::More; use Plac

    Plack::Test で HTTP クライアントのテストを書く方法 - Craftworks Tech Blog - Branch
  • Re: LLごとの標準的なHTTPクライアントで100リクエスト投げた時のベンチマーク - tokuhirom's blog

    http://subtech.g.hatena.ne.jp/mala/20100531/1275322139 mala のベンチマークにおいて、気になる点がある。それは、「HTTP プロトコルにたいするベタなライブラリ」と「HTTP プロトコルをつかうための高レベルなライブラリ」のベンチマークがまじっているという点。 前者は ruby/Net::HTTPpython/httplibperl/Net::HTTPにあたるものであり 後者は ruby/open-uripython/urllib(urllib2)perl/LWP::Simpleにあたるものである。 で、ruby/Net::HTTP と perl/LWP::Simple をならべて、LWP が遅いといわれてもなんだろうから、かけている部分のベンチマークスクリプトをおいておく。 しかし、それにしても curl はやいね。 Python

  • SSL in WinHTTP - Win32 apps

    Microsoft Windows HTTP Services (WinHTTP) supports Secure Sockets Layer (SSL) transactions including client certificates. This topic explains concepts involved in an SSL transaction and how they are handled using WinHTTP. Secure Sockets Layer SSL is an established standard for ensuring secure HTTP transactions. SSL provides a mechanism to perform up to 128-bit encryption on all transactions betwee

    SSL in WinHTTP - Win32 apps
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • WinHttpRequest object - Win32 apps

    This topic provides information about using the WinHTTP WinHttpRequest COM object with scripting languages. For more information, including the C++ API (WinHTTP) please see About WinHTTP. See Choosing a WinHTTP Interface for a comparison of these interfaces. Example // Instantiate a WinHttpRequest object. var WinHttpReq = new ActiveXObject("WinHttp.WinHttpRequest.5.1"); IWinHttpRequest * pIWinHttp

    WinHttpRequest object - Win32 apps
  • 502 Bad Gateway

    502 Bad Gateway nginx

  • yohei-y:weblog: 『Webを支える技術 ── HTTP、URI、HTML、そしてREST』という本を書きました

    このブログ、1年近くご無沙汰していました。その間なにをやっていたかというと、実はずっとを書いていました。『Webを支える技術 ── HTTP、URI、HTML、そしてREST』というなんとも挑戦的な題名のです。技術評論社さんのWEB+DB PRESS Plusシリーズの11冊目で、来月発売される予定です。 Webを支える技術 ── HTTP、URI、HTML、そしてREST山 陽平技術評論社 2010-04-08 このは、WEB+DB PRESSで連載していた「RESTレシピ」という連載がベースになっています。実は連載が1年経ったくらいから、技評さんからは書籍化のオファーをもらっていました。ただ、その時点では書いた分量も少ないし、そもそも自分に雑誌記事とは比べ物にならないくらい分量のあるが書けるとは思っていなかったので、書籍ではなく連載継続という形でトータル2年間連載をしました。

    ikasam_a
    ikasam_a 2010/03/03
    2/3書き下ろしおつかれさま
  • YappoLogs: HTTP::Request::StreamingUpload - 省メモリでrequest bodyをupload

    HTTP::Request::StreamingUpload - 省メモリでrequest bodyをupload Today I created a good wrapper for request body upload HTTP::Request. this module is use few memory on file upload. also too big file. http://search.cpan.org/dist/HTTP-Request-StreamingUpload/ http://github.com/yappo/p5-HTTP-Request-StreamingUpload DESCRIPTION HTTP::Request::StreamingUpload is streaming upload wrapper for HTTP::Request. It

  • web開発者なら知っておきたい HTTPステータスコード : LINE Corporation ディレクターブログ

    こんにちは。ブログと検索を担当している河野です。 突然ですが、皆さんは404という数字を見て何を思い浮かべるでしょうか。 この数字からWebブラウザで時折見かける「404 Not Found」を思い出す人は多いのではないかと思います。ということで、ちょっと強引ですが、今回はこの404などのHTTPステータスコードについて、ディレクターの視点で知っていた方がいいことを書いてみたいと思います。 【1】HTTPステータスコードの定義と確認方法 まずはHTTPステータスコードについて一通り説明をしたいと思います。 HTTP ステータスコードとは、「HTTPにおいてWebサーバからのレスポンスの意味を表現する3桁の数字からなるコード」とWikipediaには定義されています。 冒頭であげた404は、このステータスコードの1つで、リクエストに対応するページやファイルを見つけられなかった時にサーバが返し

    web開発者なら知っておきたい HTTPステータスコード : LINE Corporation ディレクターブログ
  • gitレポジトリをhttpで公開する

    Original Setting up a git repository which can be pushed into and pulled from over HTTP(S). まだ試しちゃい無いんですが、gitレポジトリをhttpで公開したくなった場合にどうすればいいのかについて。 何が必要か Apache ウェブサーバをもっていること Apache の設定ファイルを編集できること 設定ファイルは /etc/httpd にあるか、 Apache のドキュメントを参照してください。 Debianの場合: /etc/apache2 下にあるファイルを編集できる必要がある。 Apache を再起動できること 'apachectl --graceful' とするかもしれません。 もし、そうしない場合、 Apache を停止して、再起動してください。 注意してください、これによりあなたのサー

  • HTTP/1.1 の同時接続数について - daily dayflower

    はてなブックマーク - Fasterfoxが最強すぎる件 - 真性引き篭もり が盛り上がってたので,机上の話だけですが,いまさら書いてみます。 RFC (2616) での記述 Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number

    HTTP/1.1 の同時接続数について - daily dayflower
  • 1