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
PATCH メソッド、新しい HTTP Status Code - 日向夏特殊応援部隊
Spec はあまりミーハーに追いかけても後で痛い目にあったりするもんですが、久しぶりに面白いなーと思ったのでちょっと取り上げてみます。 ちなみに斜め読みなので記事の正確性についてはあまり保証しませんw PATCH Method for HTTP RFC 5789 にある PATCH Method for HTTP ですが、RESTful API の致命的な弱点でもある PUT がリソースの完全なる置き換えなのに対して、PATCH は差分適用である所が中々面白いです。 2.1. A Simple PATCH Example のサンプルを見てみます。 PATCH /file.txt HTTP/1.1 Host: www.example.com Content-Type: application/example If-Match: "e0023aa4e" Content-Length: 100
httpstat.us
This is a super simple service for generating different HTTP codes. It's useful for testing how your own scripts deal with varying responses. Just add the status code you want to the URL, like this: httpstat.us/200 We'll return a response like this: HTTP/1.1 {status code} {status description} Content-Type: text/plain or application/json Content-Length: {something} {any custom response headers} {st
5x performance - switching from LWP to Furl & Net::DNS::Lite
Recently I rewrote some of our code that used LWP::UserAgent to use Furl instead, and have been observing more than 5x increase in performance (the CPU time spent for each HTTP request in average has dropped 82%). The fact clearly shows that if you are having performance issues with LWP::UserAgent it is a good idea to switch to Furl. And here are my recommendations when doing so: use the low-leve
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 してしまうのが、現実的な解決策だとおもった。 現実的には、現
HTTP/1.1 の chunked encoding を使った POST / PUT を避けるべき理由 - kazuhoのメモ置き場
通信相手のサーバが HTTP/1.1 対応と確認できるまでは 1.0 と互換性のない chunked encoding は使えないし でも確認が取れた接続を使い回す = HTTP/1.1 の持続的接続を使い回して POST / PUT するってことだけど、持続的接続のタイムアウト条件は、TCP 接続確立後初回のリクエストより厳しいし 従って、POST / PUT は、べき等性がないリクエストだから持続的接続には投げるのは避けた方が無難だし ということで、基本使うべきじゃない。という話をした (http://github.com/tokuhirom/p5-Furl/commit/67c3ea52a23542a44e58869d0bcebcb53becd34a)。
Apache, Lighttpd, nginx における持続的接続と lingering close の実装について - kazuhoのメモ置き場
lingering close がなんであるかについては、Apache Performance Tuning - Apache HTTP Server Version 2.2 を参照。 Apache 2.2.16 と lighttpd 1.4.28 は、必ずアプリケーションレイヤでの lingering close を行う Apache は2秒、lighttpd は5秒 nginx 0.8.53 は直前に request body があった場合のみ SO_LINGER を利用する これは古い HTTP client が request body のあとに CRLF つけてくることがある対策だと思う HTTP pipelining の関係で RST が飛ぶ場合の対策コードはないかも 一方で、msie6 で POST の場合、あるいは safari だと常に keep-alive を disa
Re: LLごとの標準的なHTTPクライアントで100リクエスト投げた時のベンチマーク - tokuhirom's blog
http://subtech.g.hatena.ne.jp/mala/20100531/1275322139 mala のベンチマークにおいて、気になる点がある。それは、「HTTP プロトコルにたいするベタなライブラリ」と「HTTP プロトコルをつかうための高レベルなライブラリ」のベンチマークがまじっているという点。 前者は ruby/Net::HTTPpython/httplibperl/Net::HTTPにあたるものであり 後者は ruby/open-uripython/urllib(urllib2)perl/LWP::Simpleにあたるものである。 で、ruby/Net::HTTP と perl/LWP::Simple をならべて、LWP が遅いといわれてもなんだろうから、かけている部分のベンチマークスクリプトをおいておく。 しかし、それにしても curl はやいね。 Python
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Kazuho@Cybozu Labs: REST におけるトランザクションについて (Re: Web を支える技術)
といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山本 陽平) - ただのにっき(2010-04-23) 「Web を支える技術」は自分もとてもいい本だと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という２つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
