何の因果かわかりませんが、お仕事でちょっと賢いリバースプロキシサーバ（以降、RPサーバ）を作る機会が２回ありました。 HTTPヘッダの内容によってプロキシ先のサーバを動的に切り替えるようなものです。 この要件を満たすため、RPサーバには以下のようなプログラムが必要になります。 HTTPヘッダの内容を知るためにHTTPリクエストをパース プロキシ先のサーバへHTTPリクエストをプロキシ プロキシ先のサーバはRedisから取得 レスポンスをクライアントへ返す 大量のリクエストも捌ける １回目はRubyとI/O多重化のライブラリを使ってイベント駆動型のRPサーバを自作してみました。 が、振り返ってみるとこれは失敗でした。 なぜ失敗だったのか？ Rubyでイベント駆動型のサーバを書こうとすると様々なものが途端に大変になります。 イベント駆動型サーバではほとんどの箇所でブロックする処理を書けません。
GCDWebServer is a modern and lightweight GCD based HTTP 1.1 server designed to be embedded in iOS, macOS & tvOS apps. It was written from scratch with the following goals in mind: Elegant and easy to use architecture with only 4 core classes: server, connection, request and response (see "Understanding GCDWebServer's Architecture" below) Well designed API with fully documented headers for easy int
2015年5月の RFC 化完了以降、主要なウェブブラウザの HTTP/2 対応が急速に進んでいます。今年末までには、HTTPS トラフィックの過半は HTTP/2 を利用するようになるでしょう。 本セッションでは、先進的な HTTP/2 サーバとして注目されている H2O の主開発者である奥一穂が、HTTP/2 策定の背景と HTTP/1.1 に対する優位性、HTTP/2 時代にむけたウェブサイト設計のポイントについて説明します。 Since the completion of the standardization process in May 2015, Web browser vendors are rushing to support HTTP/2. It is likely that the majority of HTTPS traffic will be using HTT
2017-01-05 追記 2016年3月にエラーの標準形式RFC7807「Problem Details for HTTP APIs」が提案され、今日現在proposed standard(標準化への提唱)となっています。こちらも是非ご覧ください。 RFC 7807 - Problem Details for HTTP APIs HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様 最近はREST APIを提供しているサービスが増えてきていますね！また公開されるAPIだけでなく、Microservicesなアーキテクチャを採用して、バックエンドがWeb APIで通信するケースも増えてきているように思います。 APIを使うときはあまり気にしたこともなかったですが、いざAPIを設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
こちらです。Perl でいうと Devel::KYTProf に性質がちかい。 motemen/go-loghttp · GitHub (GoDoc) 使用例 たとえばこういうコードに… package main import ( "io" "log" "net/http" "os" ) func main() { resp, err := http.Get(os.Args[1]) if err != nil { log.Fatal(err) } io.Copy(os.Stdout, resp.Body) } % go run main.go http://example.com/ <!doctype html> ... 一行追加すると: package main import ( "io" "log" "net/http" "os" _ "github.com/motemen/go-lo
Introducing Proxygen, Facebook’s C++ HTTP framework We are excited to announce the release of Proxygen, a collection of C++ HTTP libraries, including an easy-to-use HTTP server. In addition to HTTP/1.1, Proxygen (rhymes with "oxygen") supports SPDY/3 and SPDY/3.1. We are also iterating and developing support for HTTP/2. Proxygen is not designed to replace Apache or nginx — those projects focus on
Vagrant shareとngrokを使ってみた Vagrant 1.5 and Vagrant Cloud Vagrant shareを使ってみた．今まではprivate_networkによるローカルマシンから仮想マシンへのアクセスや，public_networkによるLAN内のマシンから仮想マシンへのアクセスが可能だった．今回のアップデートで，外部ネットワークのマシンから，ローカルに立てた仮想マシンへのアクセスが可能になった． 主なアクセスは以下の2つ． 仮想マシン内に立てたHTTPサーバーへのアクセス SSHによる仮想マシンへのログイン 試してみた． 準備 Vagrant Cloudでアカウントを作成し，ログインする． $ vagrant login また，例として以下のようなVagrantfileを準備し，仮想マシンを起動しておく． Vagrant.configure("2")
File: SIGNALS [Unicorn: Rack HTTP server for fast clients and Unix] の一部を超訳しただけ
Railsでは、request.subdomainで簡単にサブドメインの判別ができます。 詳しくはRailsCastsに書いてありますが、特にgemを入れなくても、url_forに1つ機能追加するだけで、実用的なサブドメイン機能が使えます。 何が嬉しいかというと、 ja.example.com en.example.com のようなwikipedia風のURLを作ったり、ブログサイトでユーザ毎にサブドメインを切ってあげたりできるわけですね。 サブドメインは当然HTTPリクエスト時のホスト名から取得されるので、環境によってはうまく取得できない場合があります。 ローカルでテストする場合 通常localhost:3000で開発すると思いますが、これにサブドメインを付けてja.localhost:3000としても、127.0.0.1に名前解決はしてくれません。 hostsファイル（/etc/hos
準備 virtualboxとvagrantがインストールされてない場合は、公式サイトからダウンロードします。 https://www.virtualbox.org/wiki/Downloads http://www.vagrantup.com/downloads.html VMの起動 GitHubから落としてきます $ git clone https://github.com/flano-yuki/nghttp2-vagrantfile $ cd ./nghttp2-vagrantfile プラグインをインストールして、vmを起動します $ vagrant plugin install vagrant-omnibus $ vagrant upboxのダウンロードに数分、Chefのダウンロードに数分、各種インストールとビルドに20分程度かかります... nghttp2 vagrant ssh
概要 前回の続きで今回はOHHTTPStubsを使用して単体テストを行ってみました。 (テスト対象となるソースコードの概要は前回のコンテンツを参照してください) OHHTTPStubsはサーバサイドの処理を用意することなく、クライアントのみでHTTP通信のスタブを用意できるとても便利なライブラリです。 今回はTRVSMonitorというライブラリも一緒に使用しています。 XCTestは非同期処理を待たずにテストケースを終了してしまう場合があるのですが、それを防いでくれるのがTRVSMonitorです。 手順 OHHTTPStubsもCocoaPodsでインストールします。 @interface ASHTTPStubUtil : NSObject + (void)setupResponseWithFile:(NSString *)fileName statusCode:(int)status
下記の文章は、PHPのセッションIDに対する攻撃についてFull Disclosure MLに2010年に投稿された文章を和訳したものです。訳者の意見としては、攻撃の成立条件は極めて厳しく、そこまで深刻度は高くないと考えています。 とはいえ、疑似乱数列への攻撃がどのように行われるのか、その可能性を示す文章は比較的珍しいもののように思います。暗号論的に安全な疑似乱数とは何か、なぜ必要なのかといった内容を間接的に教えてくれる面白い文章だと感じましたので、今回翻訳してみました。 （以下、原文の和訳です） 原文：http://seclists.org/fulldisclosure/2010/Mar/519 Advisory (c) 2010 Andreas Bogk <andreas () andreas org> Product:PHP Version:5.3.2 以降 脆弱性の種類:暗号論的な
HRForecast の API で値を投げた時に返ってくる JSON に、これまではエラーの有無とエラーメッセージだけでしたが、POST 成功時にはグラフの情報が含まれるようになりました。 { :metricses => [ [0] { :section_name => "test_section", :id => "1", :colors => "[\"#99cc33\"]", :updated_at => nil, :service_name => "test_service", :graph_name => "test_graph", :color => "#99cc33", :meta => "{\"color\":\"#99cc33\"}", :created_at => nil, :sort => "0" } ], :error => 0 } 他にもいくつかの JSON AP
10/26(土)に開催されたHachioji.pm#33に行ってきました!台風が去ったから前日に開催が決まって、なんと7人も参加するという柔軟っぷり! もろもろと まず、突然にbayashiさんが参加して、結構話せて楽しかったです。YAPC::Asia2013に参加した多くの人が、極楽汁麺 らすたにいったことでしょう。 Data::Dumper::AutoEncodeとかたまに使うし、utf8フラグが文字列に立っているか確認するときに毎回bayashiさんのPerl5.8でUTF-8のメモという記事を調べて、コードコピペするということをしているので、大変感謝&感動でした!あと、「パッチとか書かないんですか?」と聞かれて「コードあまり書けません」ってぶっちゃけましたが、今何個かモジュールとかプロダクトのアイデアがあったので、おかげさまでやる気をもらって今年中にgithubにはあげようと思いま
Apacheのmod_proxyの設定をしたのでメモをする。 今回は、リバースプロキシ＋ある特定のパスだけ、除外条件を書いて別サーバーへプロキシした。 インストール takuya@host $ sudo aptitude install apache2 #apache2のインストール takuya@host $ sudo a2enmod proxy #mod_proxyを有効化 takuya@host $ sudo a2enmod proxy_http #httpのプロキシを使う このほかにも proxy_balancer（プロキシ機能を使ったロードバランサ） proxy_ftp ftpサーバーのプロキシ機能がある。 proxy_ajp apache tomcat アプリケーション間通信プロキシなどがある。 proxy_connect #connect メソッド（HTTPSのプロキシで使う
ここのブログは、nginx(proxyサーバ)が外からのアクセスを受け、それを thin + sinatra (アプリケーションサーバ) と mongoDB (データベースサーバ)で処理する、というWebシステム定番の三層構造で構成している。 ただ、見てわかるようにほぼ静的なコンテンツのサイトなので、アクセス毎にアプリケーションサーバを走らせる意味がない。また、このVPSの一番安いコースにおいているので、あまり贅沢に資源を使いたくない。と言ったことから生成したhtmlをキャッシュして2度目のアクセスからはアプリケーションサーバやデータベースにアクセスしないようにしている。 Webシステムによっては、アプリケーションサーバで静的なhtmlファイルを作成し負荷の軽減をしたりするが、キャッシュファイルを自前で扱うのはvalidation等色々だるいので、このブログシステムではnginxに任せてい
nginxでltsv形式のaccess.logを出力する
人間による可読性の良さと、parse処理のしやすさ、１行中の出力内容の順序にたいしてロバスト（項目の順番が変わったり追加されてもparseに失敗することは無い）という点でltsv(Labeled Tab-Separated Value)というファイルフォーマットが一時期流行りました。 もちろん一時の流行ではなく、非常に実用的な手法なので、このたびnginxの出力ログをltsv形式に変えてみました。 ◯設定 naoyaさんのブログ(http://d.hatena.ne.jp/naoya/20130205/1360088927)を引用すると、以下のような形になります。 http { … log_format ltsv 'time:$time_local\t' 'host:$remote_addr\t' 'request:$request\t' 'status:$status\t' 'size:
Hubotを導入して半年たったのでレビューします。 Hubotとはなにか いわゆるボットです。サーバー上で待機していて、こちらからコマンドを与えたりイベントが発生するとそれに応じて処理をしてくれるプログラムです。 module.exports = (robot) -> robot.respond /PING$/i, (msg) -> msg.send "PONG" 下記のような特徴を持っています。 CoffeeScriptで「どういうメッセージがきたら なにをする」というパターンをサクサク追加できる。 機能拡張のスクリプトを簡単に使い回せる。(hubot-scriptsレポジトリで公開されている) Campfire, IRC, Skype, Yammerの様々なコミュニケーションツール、HTTP等をインターフェイスとして使える。 特に重要なのは3つ目で、デプロイのコマンドはIRC経由で受け
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
