実はけっこう前からWebSocketの詳しい仕組みについて気になってて、遂に一念発起して調べてみた。何かとても良さげっぽい。 そもそもWebSocketとは Webにおいて双方向通信を低コストで行う為の仕組み。インタラクティブなWebアプリケーションではサーバから任意のタイミングでクライアントに情報の送信とかしたい事があって、例えばFacebookのチャットアプリみたいに多数のクライアントが一つのページにアクセスしてて誰かがメッセージを投稿するとそれをその他のユーザーに通知したい場合があって、そういった時に双方向通信の必要性が出てくる。 元々はWebにおいてはHTTPしか通信の選択肢が無くてHTTPのロングポーリング使って無理矢理双方向通信実現したりしてたんだけど、流石に無駄が多すぎるし辛いよねって事でWebSocketというプロトコルが作られた。 WebSocketにおいては、TCP上で
t.coなどから本当のURLを取り出す方法という記事で、短縮 URL などでのリダイレクト先 URL をチェックする方法を扱っていました。 僕もよくリダレクト先を調べようとして、そのたびにやり方を調べなおしたりしていたので、これに乗じてメモしておこうと思います。(ここでは goo.gl を使用して、http://google.com/ にリダイレクトしています。) まずは記事にあった telnet を使うやりかた。 $ telnet goo.gl 80 GET /EbHzJ HTTP/1.0 Host: goo.gl ※ goo.gl や tinyurl.com では、GET だけでなく Host も必要なようです。 telnet はあまり環境を選ばないのですが、コマンド1行で書ける(なのでヒストリーも使える)ほうが好みです。 netcat (nc) は便利です。 $ (echo "GET
2014年03月14日20:00 カテゴリTipsCode Tips - 静的リソースのURIに?をつけるべからず Webを支える技術 HTTP、URI、HTML、そしてREST 山本陽平 であればなおのことこの実装はNG。 ブラウザのキャッシュを利用できれば、余分なリクエストを減らすことができます。はてなブログでは、なるべく長い間ブラウザにキャッシュを保存するために、JavaScriptなどの一部の種類のファイルのレスポンスに、以下のようなヘッダを指定しています。 はてなブログにおけるページ表示速度改善の取り組みについて - Hatena Developer BlogはてなブログではJavaScriptを配信する際には、上記のURLのように、?よりあとの部分にabc078624b2a746c618156847827166bのようなバージョンIDを付与しています。JavaScriptが変更
Translation of: Adding meaning to your HTTP error pages! by Stuart Colville This article is licensed under a Creative Commons Attribution, Non Commercial - Share Alike 2.5 license はじめに ウェブ上で何かを検索しようとすると、既に存在しないページしか検索結果になく、それらへのリンクをクリックすることはよくあるだろう。その開いたページにデフォルトのエラー・メッセージの他に何も情報が載っていなかった場合、多くの人々は戻るボタンを押し次の検索結果を開こうとするだろう。 サイト製作者である我々はもっと訪問者に意味のあるエラーページを作成することができる。そうすればたとえエラーページであっても訪問者をサイトに留まらせ、彼ら
Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus) 作者: 山本陽平出版社/メーカー: 技術評論社発売日: 2010/04/08メディア: 単行本（ソフトカバー）購入: 143人 クリック: 4,320回この商品を含むブログ (183件) を見る Python2系でurllibとurllib2に分かれていたHTTP関係のコードは、Python3でurllibモジュールに統合されました。 Pthon3でHTTP POSTをする場合にurllibをどう使えばいいのかについて、はてなにログインするスクリプトを例にして比較したいと思います。GETは簡単なんでパス。 全体的な流れとして データをURLエンコードして送信 cookieはCookieProcesssorでCookieJarオブジェクトを処理 接続するとレスポンスオブジェクトが返るので
あちこちのウェブサイトのHTMLソースを見ると、CSSファイルやJSファイルを読み込むlink要素やscript要素のファイル名の末尾に「?xxx=123」のような、いわゆるクエリーがついているのを頻繁にみかけます。 例えばWordPressでjqueryを読み込んだときなど、 <script src="http://user-domian/wp-includes/js/jquery/jquery.js?ver=1.6.1"></script> と、jQueryのバージョン番号を示すクエリー文字列がついています。CSSファイルやJavaScriptファイルはCGIではないので、このクエリーを解釈して使っている訳ではありません。 知っている人は「な～んだ」って感じだと思いますが、この「?ver=1.6.1」の役割について紹介します。 １．キャッシュを制御する ページ読み込みと同時に読み込まれ
ステートレスとは何か
RestWiki をたまに見直すと新たな発見があって面白い。 たとえば先日、「ステートレスなやりとりとは何か(What is Stateless Interaction?)」という箇所を見つけて、興味深く読んだ。このページは以前も絶対に読んでいるはずなのだが、 人間は忘れてしまうものである。 RestWiki の例でも充分わかりやすいのだけれど、自分でも例を思いついたので書きとめておく。 ステートフルサーバとステートレスサーバはどう違うのか。 まずは、ステートフルの例: 客: こんにちは 店員: いらっしゃいませ。○○バーガーへようこそ 客: ハンバーガーセットをお願いします 店員: サイドメニューは何になさいますか? 客: ポテトで 店員: ドリンクは何になさいますか? 客: ジンジャーエールで 店員: +50円でドリンクをLサイズにできますがいかがですか? 客: Mでいいです 店員:
ApacheとWebブラウザ間でデータをやり取りするために利用するプロトコル「HTTP」について説明します。 前回までは主に，Apacheの各種機能を使うための設定方法を紹介してきました。さらに深くWebサーバーをカスタマイズするとなると，WebサーバーとWebブラウザの間でデータをやり取りする仕組みについても理解しておく必要があります。 そこで第8回は，Webで利用されているプロトコル「HTTP」そのものと，HTTPを利用した通信の仕組みを説明します。 第1回では，WebブラウザとWebサーバーは「HTTP（Hyper Text Transfer Protocol）」と呼ばれるプロトコルを利用して通信することを説明しました。プロトコルはいわば言葉のようなものです。文法に沿って言葉がやり取りされるように，HTTPにおいても特定のルールに則ってサーバーとクライアントが通信します。例えば，「i
研究内容 クッキーに有効期限を設定する研究です。 詳細 有効期限を設定しなかった場合 有効期限を設定しない場合、有効期限はブラウザを閉じるまでです。 これでは不便ですね。有効期限を設定して、ブラウザを閉じても クッキーが消えないようにする必要があります。 有効期限の設定方法 クッキーの有効期限を設定するには、HTTPヘッダの Set-cookie で次のようにします。 Set-Cookie: (保存するクッキーデータ); expires=(有効期限); クッキーの後ろに、; で区切って有効期限を指定すればいいようです。 有効期限は、日付と時刻で指定します。 ここで指定した日付、時刻を越えると自動的にクッキーが削除されます。 有効期限の書式 この有効期限、 どのような書式で設定するのかというと、 例えば次のようにして指定します。 Set-Cookie: (保存するクッキーデータ); expi
HTTP cookie（エイチティーティーピークッキー）は、マジッククッキーの一種。単にクッキー（cookie）とも表記される。 RFC 6265などで定義されたHTTPにおけるウェブサーバとウェブブラウザ間で状態を管理する通信プロトコル、またそこで用いられるウェブブラウザに保存された情報のことを指す。ユーザ識別やセッション管理を実現する目的などに利用される。 HTTPは元来ハイパーテキストにおいて単にファイル転送を行うために開発されたため、同じURLへのアクセスならその状況によらず同一の情報源[1]を提供することが前提となっている。動的なコンテンツ生成の仕組みとしてフォームが導入されているが、これは要求に直接対応する応答だけに影響をおよぼす。言い換えるとHTTPでは、同じ瞬間に同じ内容の要求を行っていれば、そのクライアントが以前にどのような通信を行っていても区別されない。HTTPはその意
「http://」の「//」は要らなかった――Webの父語る Webアドレスの「http://」の「//」は無用だ――インターネットの父ことティム・バーナーズ・リー氏はWebの将来についてのインタビューでこのように語った。「インターネットを発明したころに戻れるとしたら、何を変えたいか」という質問に対し、同氏はWebアドレスの最初の部分（http://）を挙げた。http://はトップから始まることを示すためのものだったが、「誰も『http://』以外で//を使っていない」「考えてみれば、//が不要だということが分かる。//なしで設計することもできたはずだ」とし、「当時はいいアイデアに思えたのだが」と語った。 Sir Tim Berners-Lee admits the forward slashes in every web address 'were a mistake'（Daily M
2007年2月11日(日) 建国記念の日 ■ 無題 _ 障害連絡を受ける携帯に深夜にメールが飛んできて、すわ何事と起きてみたら、それが spam だったときのやるせなさといったら。 _ で、起こされた。さっき。 _ あした受信拒否設定しとこ。とりあえず、寝る。 2007年2月13日(火) ■ IE6 KeepAlive _ ちょと話題の これとか これとか これとか。 _ えーと、サーバが Connection: close を返しておきながらサーバの方からは TCP を切断しない場合、クライアントの IE はタイムアウトするまで仕事をサボるから遅い（≠重い）、ということでいいのかな。へー、こんな問題あるんだねぇ。知らなかった。今まで聞いたことなかったけど、よほどレアなケースなんだろう。 _ でも、うーん、これって IE のバグなのかなぁ？ _ HTTP ってアプリケーション層のプロトコル
最速インターフェース研究会 :: 最近IE6でWikipedia日本語版の表示が異常に遅いのはKeepAliveのせい 2月初めぐらいからか、キャッシュが空の状態で日本語版のWikipediaを表示すると、IE6が1分間ほど固まる、という不具合があるそうだ。 で、Proxomitronでレスポンスとか調べてみてたりしたのだけれど、プロキシ経由だと問題なく表示される。 これ、私が普段仕事で使っているIE6でも再現していたので、HTTP Debugging Proxy - Fiddlerを使ってブラウザのHTTP通信をキャプチャして調べてみました。 （※2007/02/13追記：upload.wikimedia.orgで対策され、既に本現象は解消されています） どうやら画像ファイルhttp://upload.wikimedia.org/wikipedia/ja/b/bc/Wiki.pngの読み
2006年12月22日(金) ■ HTTP トランザクションを減らすには _ HTTP のリクエストとレスポンスを効率よくやりとりするためには、HTTP/1.1 の persistent connection を使ったり、persistent connection の上でさらに pipelining したりとかいう方法がある。 この前の /.j の議論では区別がついてない人がいたみたいだけど、ちゃんと区別してね。 _ でも、これ以外にもまだ方法はあるはずだよね。リクエストとレスポンスを複数繰り返すから接続数の問題が出てくるのであって、リクエストとレスポンスを1回やりとりするだけで複数のリソースを受け渡せるようにすればいい。 _ ……ってことで、3年近く前に実験したことがあるんだわ。クライアントは IE、Mozilla、Opera で試したんだけど、メモを見ても当時どのバージョンを使ったのか
2006年12月21日17:30 カテゴリSciTech HTTPサーバーのパイプライン対応 今回は、HTTPのパイプラインの話。 「RFC2616の同時接続数の規定」@水無月ばけらのえび日記 「HTTPの同時接続数はどうあるべきか? (slashdot.jp) 」というお話。誰も原文を引用していないのが悲しかったので、引いておきます。 スラッシュドット ジャパン | HTTPの同時接続数はどうあるべきか?-taka2さんのコメントそれなら、「同時接続」しなくても、結果が返ってくる前に次のリクエストを送出して「リクエスト送信」と「結果受信」を並行して行えるようになれば、スループットの向上は見込める。 それがパイプライン化 [mozilla-japan.org]で、同時接続するよりも効率が良い。パイプライン化の前に、HTTPで何が行われているのかを、実際に見てみよう。telnetコマンドがあ
Hippo2000 (2000/7/28) LWP::UserAgentモジュールなのです。 作者はGisle Aasさんです。メールで許可をいただきました。 2001/6/21：山宮隆さんからの指摘を受けて、余分な「；」を削除しました。 目次 名前 概要 説明 メソッド 参考資料 著作権 名前 LWP::UserAgent - WWW ユーザ・エージェント クラス 概要 require LWP::UserAgent; $ua = LWP::UserAgent->new; $request = HTTP::Request->new('GET', 'file://localhost/etc/motd'); $response = $ua->request($request); # or $response = $ua->request($request, '/tmp/sss'); # or
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
