クローリングしにくいものに挑戦 公開用e-ZUKA Tech Night in 博多! -fin tech特集- Bitcoinのブロックチェーンでできるコントラクトshigeyuki azuchi
HerokuのAPIデザイン
Herokuが自ら実践しているAPIデザインガイドをGithubに公開した． “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて，ビジネスロジックに集中すること目的としている．Heroku特有なものではなく，一般にも十分適用できる知見となっている． 最近は，モバイル向けにAPIをつくることも多いため，勉強もかねて抄訳した．なお内容は，HTTP+JSONのAPIについて基本的な知識があることが前提となっている． 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと．例えば，“成功"を示すステータスコードは以下に従う． 200: GETやDELETE，PATCHリクエストが成功し，同時に処理が完了した場合 201: POSTリクエストが成功し，同時に処理が完了した場合 202: POSTやDELETE，PATCHリク
Lennyのapt-get(sources.list)をアーカイブ参照に変更する - labunix の ラボゆにっくす
■とうとうLennyがアーカイブに移動した。 ※それまではセキュリティサポートの修正だけで回避できた。 Lennyのセキュリティサポート終了後の「sources.list」の設定 http://d.hatena.ne.jp/labunix/20120211 ■最後に成功したログ 私がlennyのapt-getが全滅するようになったことに気づいたのは27日の朝なので、 4/25 18:50 〜 4/27 10:00頃の間、後述するアーカイブの日付も併せて推測すると、 24、25の間にアーカイブに移動、26日にメインから削除されたのだと思う。 Debian公式のアナウンスは特に見当たらなかった。 $ su root -c 'grep debian.org /var/log/squid/access.log.*' | \ grep ".deb" | grep " [23]0[04] " | aw
mitmproxy - an interactive HTTPS proxy
Command Line mitmproxy is your swiss-army knife for debugging, testing, privacy measurements, and penetration testing. It can be used to intercept, inspect, modify and replay web traffic such as HTTP/1, HTTP/2, WebSockets, or any other SSL/TLS-protected protocols. You can prettify and decode a variety of message types ranging from HTML to Protobuf, intercept specific messages on-the-fly, modify th
xkcd: 1337
この一連の5部作のタイトルは1377。これはleet（英語圏における2ch語に相当する記法）をleetで書いたもの。またひょっとしたら、ジョージ・オーウェルの1984も意識しているのではないかと思う。 xkcd: 1337: Part 1 母「あんたまさか、お隣さんのWiFi使ってるんじゃないでしょうね？」 子「そうだけど何か？」 母「その管理者は・・・イタズラ好きなのよ」 子「大丈夫だって。何なら今からセキュアなVPN経由にするさ」 子「何だと！ トンネルしようとすると一瞬でコネクションがブチ切れるぞ」 『VPNですって？ あら可愛いわね。sshもやめときな』 子「ありえん。誰かが俺の見てるページに埋め込みやがったァッ！ 手でッ！ リアルタイムにTCPストリームを編集してやがるッ！」 子「そんなに素早いヤツがいるわけがねェーッ。この管理者、何者ォッ？」 ロバーツ夫人「おーやおや、お隣んと
なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes
Intro Google が SPDY の開発を始めたのは 2009 年で、 2012 年に HTTP2.0 のドラフトとして採用されたあたりからちょっと話題になりました。 翌 2 月には新たなプロトコル QUIC の存在が Chromium のソースからリークしたのですが、しばらくは音沙汰なく。 6 月に入ってやっと Google から公式アナウンスとドキュメント類が出ました。 去年から今年にかけて立て続けに出てくる新しいプロトコルの話。 なぜ今 Web のプロトコルが見直されるのか？ 何が問題で、なぜ Google はそれらを作り変えるのか？ SPDY や QUIC は Google の独自プロトコルだけど、それは本当にただの独自プロトコルで終わらせていいのか？ 20% ルールで作ってみた Play プロジェクトでしかないのか？ こうした新しい動きには、かならず「それまで」と「今」を踏
RFC 3986 - Uniform Resource Identifier (URI): 一般的構文
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
HTTPの新ステータスコード「451 Unavailable for Legal Reasons」を、グーグルのTim Bray氏がIETFに提案
HTTPの新ステータスコード「451 Unavailable for Legal Reasons」を、グーグルのTim Bray氏がIETFに提案 WebブラウザとWebサーバのあいだでやりとりされる通信プロトコルのHTTPには、リクエストに対するレスポンスを表すためのさまざまなステータスコードがあります。例えば、「200 OK」「404 Not Found」などはその代表的な例です。 ここに新しいステータスを追加しようという提案がIETFに対して行われました。提案したのはXML仕様の策定に関わった主要な人物であり、現在グーグルでAndroidのデベロッパーアドボケイトをしているTim Bray氏。 提案されたステータスコードは「451 Unavailable for Legal Reasons」（451 法的な理由によって利用不可）です。 ISPとサーチエンジンに影響するようだ 提案では
機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記
WebアプリケーションにおいてJSONを用いてブラウザ - サーバ間でデータのやり取りを行うことはもはや普通のことですが、このときJSON内に第三者に漏れては困る機密情報が含まれる場合は、必ず X-Content-Type-Options: nosniff レスポンスヘッダをつけるようにしましょう(むしろ機密情報かどうかに関わらず、全てのコンテンツにつけるほうがよい。関連:X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記)。 例えば、機密情報を含む以下のようなJSON配列を返すリソース(http://example.jp/target.json)があったとします。 [ "secret", "data", "is", "here" ] 攻撃者は罠ページを作成し、以下のようにJSON配列をvbscriptとして読み込みます。もちろ
bingbotのクロール頻度が多すぎて重いので、robots.txtで調整した | colori
サイトを運用していると、時たま謎のサーバー負荷に悩まされることがありますが、今回はBingのクローラーがやらかしてたという話です。 2013/1/16 追記：robots.txtでも調整できない場合の対策も盛り込みました。 ユーザーのアクセスが最も多いお昼時の時間帯でこれですよ。 157.55.35.85 - - [29/Oct/2012:14:07:25 +0900] "GET /***/ HTTP/1.1" 200 5503 "-" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)" 157.55.35.85 - - [29/Oct/2012:14:07:25 +0900] "GET /***/ HTTP/1.1" 200 5503 "-" "Mozilla/5.0 (compatible;
The OAuth 2.0 Authorization Framework
Abstract OAuth 2.0 は, サードパーティーアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可フレームワークである. サードパーティーアプリケーションによるアクセス権の取得には, リソースオーナーとHTTPサービスの間で同意のためのインタラクションを伴う場合もあるが, サードパーティーアプリケーション自身が自らの権限においてアクセスを許可する場合もある. 本仕様書はRFC 5849に記載されているOAuth 1.0 プロトコルを廃止し, その代替となるものである. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It re
Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト
移転しました http://please-sleep.cou929.nu/20130121.html
500,000 requests/sec – Modern HTTP servers are fast
A modern HTTP server running on somewhat recent hardware is capable of servicing a huge number of requests with very low latency. Here’s a plot showing requests per second vs. number of concurrent connections for the default index.html page included with nginx 1.0.14. With this particular hardware & software combination the server quickly reaches over 500,000 requests/sec and sustains that with gr
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Shinobra.com