ウェブ発明主、たったひとつの後悔
人生でやり直したい事って誰でもありますよね。 ワールド・ワイド・ウェブの父、ティム・バーナーズ＝リー（Tim Berners-Lee）氏は、もう一回ウェブを最初からやり直せるなら｢絶対ああはしないのに｣と悔しく思ってることが一つあるそうです。それは... ウェブアドレスのhttpの後にある、あの変てこりんなダブルスラッシュ（//）。あれを消すこと！ 当時あれが当たり前でしたが、後になって別に要らないじゃん、と分かったんだそうな。だったら｢http:｣ とスッキリしておけば済んだものを｢http://｣としてしまったばかりに...タイプと印刷に一体どれだけの時間と手間を浪費し、木を余分に切り倒したことか...と、NYタイムズに語ってます。 まーしかし、今みんながインターネットで浪費してるその他諸々に比べたら、スラッシュ2本のロスぐらい序の口、序の口。あんまり夜な夜な自分を責めないでいてくれる
HTTP::Parser::XS - a PSGI compatible, fast http parser - kazuhoのメモ置き場
んー、と思って、書いた。GitHub - kazuho/p5-http-parser-xs: a fast http parser BLURB は、 PSGI のリクエストオブジェクトを返す 高速 同期 httpd, 非同期 httpd のどちらを実装する際にも使用可能 POST コンテンツのハンドリングはご自分で いったんファイルに入れたり、いろいろ要件があるし、パース作業は発生しないので Perl でもあまり遅くならないため てな感じです。以下ベンチマーク。 $ ./http-parser-vs-xs-benchmark.pl Rate HTTP::Parser HTTP::Parser::XS HTTP::Parser 2978/s -- -95% HTTP::Parser::XS 54348/s 1725% --ベンチマークに使ったコードは、以下のとおり。 #! /usr/bin/
ネットワークプログラミングの基礎知識
ネットワークプログラミングの基礎知識 ここでは IP アドレスやポート番号、クライアントとサーバの役割などを説明し、 perl・C言語・Java などでソケット (Socket) を使った HTTP クライアントや POP3 クライアント、簡単なサーバを作成してみます。 要はネットワークプログラミングをやってみよう、ということです。 このページのサンプルプログラムは、RFC などの規格に準拠した「正しい」プログラムではありません。 また、全体的にエラー処理が不十分です (今後改善する予定です)。 あくまでも概要を理解するためのサンプルととらえてください。 もし本気でしっかりとしたクライアントやサーバを書きたいなら、このページを読んだ上で、 さらに RFC を熟読し、そして wget・Apache・ftp コマンドなどのソースを参考にしてください。 このページに間違いを見付けたら、掲示板 で
Big Sky :: ReverseHttpで誰よりも速く「はてなブックマーク」に反応するツール書いた。
ReverseHttp面白いですね。 ReverseHttp Tunnel HTTP over HTTP, in a structured, controllable, securable way. Let programs claim part of URL space, and serve HTTP, all by using an ordinary HTTP client library. http://www.reversehttp.net/ ただ勘違いされやすいのが「何がReverseなの」という部分。通常ブラウザからリクエストが送信され、それに対する応答がサーバから返されます。ReverseHttpはサーバで何かアクションが起きた場合に、ブラウザ側がその通知を受信する...なんて事が出来るプロトコルです。仕組みはcometというlong pollに似た仕組みで、サイトのdemo
Big Sky :: C++で軽量Webサーバ書いた。
書いたといっても結構前からあったのですが、いらん所を削ぎ落として軽量Webサーバとして仕立て上げました。 軽量とは言えど、CGIを使って結構色々動きます。 例えば、ソースアーカイブを解凍したらCGIがあって、apacheから見える場所にコピーして...とか面倒くさかったりしますよね。 おれは今すぐWebサーバを起動したいんだ！そして今いるディレクトリのファイルをWebサーバからサーブしたいんだー！ って事ないですか？blogソフトウェアをダウンロードして今すぐ試したいけど、apacheインストールされてなかった...とか悲しすぎます。 今回紹介する"tinytinyhttpd"(tthttpd)はそんな、小さい様で大きな問題を解決出来るかもしれないソフトウェアです。 mattn's tinytinyhttpd at master - GitHub tiny tiny httpd http:
TIPS >> Blog Archive >> URL の最大長は何文字?
ユーザーエージェントおよびサーバの実装に依存します。スキーム、ホスト名を含めて、255 バイト以下は安全です。メジャーなブラウザとサーバに限定すれば、2000 バイト程度までは使えるでしょう。 SGML では 1024 文字 HTML のスーパーセットである SGML では、LITLEN=1024 文字とされています。 RFC2070 | URL の長さの制限って | HTML 4のSGML宣言 HTML 4.01 では 65536 文字 HTML 4.01 では LITLEN=65536 文字です。 HTTP では未定義、255 バイト以下を推奨 RFC2616 (HTTP/1.1) には、URL の長さに関する規定はありません。ただし、 Note: Servers ought to be cautious about depending on URI lengths above
FirefoxのHTTPプロトコルハンドラを置換してローカルプロキシっぽい動作をさせる - 遥かへのスピードランナー
先日の僕のFirefoxアドオン(XPCOM)でHTTPプロクシを実装するの記事の発展系として、piroさんがローカルプロキシっぽいことをローカルプロキシを立てずにやろうとして挫折したことのまとめというすばらしくためになる記事を書かれています。 この記事の中でpiroさんは「特定のURIにアクセスしようとした時だけ、あらかじめ定義しておいたルールに従って別のリソースを返す」ことを実現するために、3つのやり方を提案しています。 ローカルプロキシを実装して、その中でリダイレクトするやり方。 http-on-modify-requestイベントのタイミングでリダイレクトするやり方。 nsIContentPoilcyのshouldLoad()の中でリダイレクトするやり方。 で、結論として2,3で目的を達成するのは難しそう、とのことなのですが、僕がかねてから考えていた4つ目のアイデアがあって、ちょっ
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
事例は重要だが、その内容の公開レベルを考えることはもっと重要 - wakatonoの戯れメモ
あー…1つやらなきゃいけないことが…orz ライトニングトーク自体久々。 やったのは、Webtunnelの紹介と危険性、そして対応。 プレゼンテーション資料はこちら。 オレは別に、管理が好きなわけでもなければ、品質マニアでもない。 でも、ISMS(ISO27001）、PMS（JIS Q 15001）、QMS（ISO9001）に共通する特徴である「マネジメントシステム」の構築と運用管理には興味があるし、部分的にではあるけど（出来る範囲で）実践してるつもりｗ JISQ15001:2006をベースにした個人情報保護マネジメントシステム実施のためのガイドライン 第1版の6ページ「1. 個人情報保護マネジメントシステムについて」の記述に、以下のような記述がある（わかりやすいように、一部箇条書きにした） 方針を作成し、 それに基づいて計画を作成し(Plan)、 実施し(Do)、 点検し(Check)、
堀愚霊瑠の指摘で気付いた、はてなスターの静的ファイルとか想像以上にアレな件 : にぽたん研究所
id:HolyGrail (堀愚霊瑠氏) の「はてなブックマークが重い件について、Page Detailerというツールを使って調べてみる - id:HolyGrailとid:HoryGrailの区別がつかない日記」とか見てて、色々問題点が指摘されてて、うん、まぁそうだねーとか色々と思いつつ、YSlow は、有用なツールである反面、減点基準が必ずしも全てのサイトに適合しないというか、ハッキリ言ってしまえば Yahoo! Inc. 基準すぎるので、鵜呑みにし過ぎるのもどうかなーとか思ってた。 で、気になったのは 13. Configure ETags ETagsっていうのはサーバ上のファイルとブラウザのキャッシュが一致しているかどうかを検証するためのものなのですが、正しく利用できていないのであれば、ETagsは無駄なだけなので取り除いてやりましょう、という項目です。 http://s.hat
BASIC 認証でログアウトを可能にする方法 - kazuhoのメモ置き場
Cookie でログイン状態を管理すればいいんじゃいのかな。 まず、ログインボタンを押した時「だけ」is_logged_on を真にする。 HTTP/1.1 Authorization Required Set-Cookie: is_logged_on=1 WWW-Authenticate: Basic realm="Hoge123456" ...サーバ側では、Basic 認証のパスワードがあり、かつ、is_logged_on の値が真であることをチェックすればいい。 GET / HTTP/1.1 Cookie: is_logged_on=1 Authorization: Basic ... ... HTTP/1.1 200 OK ...で、ログアウトの際には、Cookie を消す。 HTTP/1.1 200 OK Set-Cookie: is_logged_on=0 ...そして、is_
kmuto’s blog
View this post on Instagram A post shared by kmuto (@mutokenshi) View this post on Instagram A post shared by kmuto (@mutokenshi) View this post on Instagram A post shared by kmuto (@mutokenshi) View this post on Instagram A post shared by kmuto (@mutokenshi) View this post on Instagram A post shared by kmuto (@mutokenshi) View this post on Instagram A post shared by kmuto (@mutokenshi) View this
FirefoxのlivehttpheadersでHTTPリクエストの中身が見られるしくみ - bits and bytes
サーバに送っているHTTPリクエストのヘッダやレスポンスのヘッダが見られるFirefoxのextension livehttpheaders がどうやってこの機能を実現しているのか調べてみました。 HTTPリクエストを送るタイミングでイベントを捕まえることができるんだろうと予想して探してみるとLiveHTTPHeaders.jsの43行めからのaddToListener()に function addToListener(obj) { ... snip ... // Should be a new version of Mozilla/Phoenix (after september 15, 2003) var observerService = Components.classes["@mozilla.org/observer-service;1"].getService(Compone
HTTP/1.1 (DELETE, GET, HEAD, PUT, POST) : Alan Dean
Diagram An activity diagram to describe the resolution of HTTP response status codes, given various headers. The diagram is available in various formats: http-headers-status.gif (205 kb) http-headers-status.jpg (340 kb) http-headers-status.png (447 kb) http-headers-status.svg (315 kb) please see request for assistance below The Visio diagram, published on Google Code Request for assistance
第1回 まずは「クッキー」を理解すべし
Webアプリケーションのぜい弱性がなかなかなくならない。メディアなどでも盛んに取り上げられているにもかかわらず，である。特に，セッション管理がからむアプリケーションのぜい弱性には，気付かないことが多い。具体的には「クロスサイト・リクエスト・フォージェリ」（CSRF），「セッション・フィクセーション」などである。これらはクロスサイト・スクリプティング，SQLインジェクションといった比較的メジャーなぜい弱性に比べて認知度が低く，対策も進んでいない。 原因の一つは，アプリケーションの開発者が原因を正しく理解していないこと。CSRFやセッション・フィクセーションについて言えば，セッション管理に使うクッキー（cookie）の動作を理解していないと対策が難しい。ところが最近の開発環境では，セッション管理の仕組みが隠ぺいされているため，必ずしもこの知識は要求されない。こうした開発者は容易にはぜい弱性に気
Macのネット環境高速化「dolipo」はナゼこんなに速いのか | Creazy!
[追記 2008/02/29 12:55] 予想以上の反響を頂いているのですが、polipoの特徴の意訳部分がかなり曖昧で一部誤った表現をしているため、随時修正・追記しております。面倒だとは思いますが技術的な部分に興味のある方は、追記部分まで読んで頂ければと思います。 また、間違っている部分のツッコミ大歓迎です。コメントなりTBなり頂けますとありがたいです。 え〜、一部のMacユーザの間でdolipo祭り開催中です。 dolipo – drikin.com dolipoというのはこんなソフトです。 ごく一部で話題になり初めてるようですが、polipoは個人用にネットワークの高速化に特化したプロキシーサーバーで、実際試してみたところ、光の自宅回線ですら、mixiやFlickrが劇的に快適になったので、感動のあまり、Mac用GUIを作成しちゃいました。 via: Drift Diary12:
導入メリット | ロードバランサー NetScalerの導入によって得られるメリット
Citrix NetScaler - Google, Yahoo!, Amazon, mixi, 魔法のｉらんどが選んだロードバランサー(負荷分散装置) 本サイトはCitrix認定 Solution Advisorである株式会社サーバーワークスが運営しています NetScalerは、従来のロードバランサ機能、Webサーバの負荷を軽減するアクセラレーション機能、サイトの安全性を高める高度なセキュリティ機能を集約し、Webサイトの安全確実な運営の実現と、トータルコストの削減という相反する要求を両立できる、優れたアプライアンス製品です。 メリット１：Webサーバが軽くなる！Webサーバの数が減らせる！ TCPコネクション集約 NetScalerは、多数のクライアントから送信されるTCPのコネクションを集約してWebサーバへ渡します。TCPの接続処理はWebサーバのCPU、メモリを消費する処理であ
リクエストをいじれば脆弱性の仕組みが見えるのだ！
telnetでリクエストを打つのは面倒…… クウ 「うーん。めんどくさい……」 ジュンさんにWebアプリエンジニアとして重要な基礎、HTTPのしくみを教えてもらったクウは、引き続きHTTPと格闘中だ。 クウはジュンさんに教わったとおりtelnetを使ってHTTPを勉強していた。しかし、telnetで静的ファイルの閲覧などは比較的簡単にできるのだが、肝心のWebアプリケーションの閲覧を行うには非常に面倒であった。 ユウヤ 「どうしたの？」 クウ 「HTTPの勉強しようと思ったんだけど、コマンドをいちいち打ち込むの大変なんだよね……」 ユウヤ 「なんかそういうの、簡単にできるツールあるんじゃないの？」 クウ 「ああ、そうか。よく考えたらそういうのありそうだね。ちょっと探してみよっと」 ユウヤ 「まあ、それはいいとしてだ。昨日頼んでおいた資料ってどうなった？」 クウ 「ああっ。ごめん！ 共有サー
もいちどイチから！ HTTP基礎訓練中 第1回 XSSは知ってても、それだけじゃ困ります？ ― ＠IT
分かってるつもりではあるけれど…… クウはベンチャー企業で働くWebアプリケーションのエンジニア。でもそこは小さなベンチャー企業、セキュリティのことは分かっていながらも、動くものを納品するので精いっぱい……。今日は納品のため、客先でミーティングに参加していた。そしてお客様から受けた指摘は、こんな一言だった。 お客さん 「……で、このWebアプリケーション、セキュリティは大丈夫なんだよね？」 クウ 「は、はいっ！ もちろんです！」 お客さん 「じゃあ、これからもよろしく頼むよ」 クウ、ユウヤ 「よろしくお願いしますっ！」 無事、お客さんとのミーティングを終えたクウとユウヤの2人は、近くの喫茶店で一息いれることにした。 クウ 「最近はセキュリティのことを聞かれることがかなり増えてきましたねぇ」 ユウヤ 「ああ、そうだね。営業の段階から『セキュリティはどう担保されているんだ？』なーんてことをいわ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
W3C準拠なHTTPパンティ - Engadget Japanese