ソースに一行追加するだけですべての HTTP 通信をロギングするモジュールを書いた #golang - 詩と創作・思索のひろば
こちらです。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
HTTP::Entity::Parser をリリースしました - blog.nomadscafe.jp
HTTP::Bodyと互換性のある HTTPのEntityをパースするモジュールをリリースしました。 https://metacpan.org/release/HTTP-Entity-Parser https://github.com/kazeburo/HTTP-Entity-Parser/ HTTPのEntityってのは、こういう範囲を指します。 POST /foo HTTP/1.1 # Not part of the entity. Content-Type: text/plain # ┬ The entity is from this line down... Content-Length: 1234 # │ # │ Hello, World! ... # ┘ 元ネタは「java - What exactly is an HTTP Entity? - Stack Overflow」
httpstatus コマンドで、HTTP のステータスコードをすばやくしらべる! - tokuhirom's blog
一般的な Web Programmer ならば、HTTP Status code はすべて暗記していると聞きました。 しかし、僕は初心者なので、なかなか覚えきれていないので、HTTPのステータスコードをさがすのに便利なツールを用意しました。App::httpstatus です。インストール方法は cpanm App::httpstatus です。というか依存とかないのでhttp://api.metacpan.org/source/TOKUHIROM/App-httpstatus-v1.0.0/httpstatus をコピーしてくればうごきます。 使い方は以下のとおりです。 4xx なコードを列挙する。 % httpstatus 4 400 Bad Request 401 Unauthorized 402 Payment Required 403 Forbidden 404 Not Foun
手軽に使える forward http proxy : stone, Tinyproxy - 酒日記 はてな支店
直接グローバルに繋がる経路をもたないホストから http アクセスしたいので http proxy を使いたい。Squidは定番ですが、もう少し手軽なのはなにかないかと思っていたところ twitter で教えていただきました。ありがとうございます。 reverseじゃなくてforwardなhttp proxyでsquid以外って手軽なの何かないか。Apacheをそれだけのために動かすのはちょっと…てかんじ 2012-10-23 17:57:44 via YoruFukurou @fujiwara stone とか? 2012-10-23 18:03:07 via web to @fujiwara @fujiwara うちはtinyproxyつかってますよ。 2012-10-23 19:01:47 via Echofon to @fujiwara Stone Simple Repeater
先輩と覚える HTTP ステータスコード
gistfile1.md 先輩に学ぶ HTTP Status Code 超雑にまとめました。修正してください。 登場人物 アプリケーション先輩: いつも忙しい。横に広がるのが得意(デブじゃない)。 後輩: 頼んでばっかしで役に立たない。 サーバー先輩: アプリケーション先輩と仲がいい。Unix Socket でつながるくらい仲良し。 プロクシ先輩: アプリケーション先輩とかサーバー先輩と後輩の間を取り持って代わりに伝えたりしてくれる。たまに勝手にレスポンスを書き換える。 1xx 系 100 Continue 後輩「あ、先輩！お願いが！」 アプリケーション先輩「おー、聞いてやる。詳しく話せ」 101 Switching Protocols 後輩「せんぱーい、お願いなんですけどー」 アプリケーション先輩「ちょっと待て、お前 HTTP 1.0 で喋るな、 HTTP 1.1 か TLS 1.0 で
HTTPで正しくキャッチボールをするには | Lab by engineering@dwango.jp
皆さんはキャッチボールは好きですか? 私はバスケットボールの方が好きです。 キャッチボールは、自分と相手双方がボールをうまくキャッチできるように投げる必要があります。これは、サーバーとクライアントの間でも同じで、クライアントから投げられたボール(リクエスト)をサーバーは正しく投げ返す(レスポンス)必要があります。 ここで、サーバーがボールをあさっての方向に投げたり、異常なスピードで投げ返すとどうなるでしょうか。おそらくクライアントはそのボールを取ろうとしますが、追いつけずにボールを落としたり、どこかにぶつけたりしてしまうでしょう。 今回は、HTTPについて、どうして正しくレスポンスを返さないといけないのかということについて、Rackを使用して解説していきます。 対象読者 Webアプリケーション開発に興味のある方、これから開発を行おうとしている方 Rackについて まず、今回使用するツール
HTTP/1.1 における Keep-Alive と HEAD の関係性について - tokuhirom's blog
HTTP/1.1 においては、HEAD リクエストの場合には Message Body を送信してはならないということにはなっているのですが、現実的には、Message Body をおくりかえしてくるアホなサーバーがおおい。たとえば Plack では Plack::Middleware::Head を明示的に使用していない場合、普通にやると HEAD でも message body をかえしてしまうだろう。 というわけで、HEAD で Message Body をかえしてくれるサーバーがおおいのだが、Message Body をかえされてしまうと、Keep-Alive しているときにこまる。次のリクエストとまじる。 この問題にたいするよい解決策はないので、HEAD リクエストを送信した後には connection を close してしまうのが、現実的な解決策だとおもった。 現実的には、現
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.dotcloud.com/announcing-hipache-dotclouds-open-source-webs