Installing software by piping from curl to bash is obviously a bad idea and a knowledgable user will most likely check the content first. So wouldn't it be great if a malicious payload would only render when piped to bash? A few people have tried this before by checking for the curl user agent which is by no means fail safe - the user may simply curl the url on the commandline revealing your malic
WebAPIの仕様を記述する方法はいくつかあると思う。 普通に日本語で記述する JSON Hyper-Schema、WADL、RAML、Swaggerなどを使う 仕様書の代わりにプログラムを書く HTTPメッセージそのものを記述しておく でも、文法にばらつきがあったり、読みにくかったり、ツールのセットアップが面倒だったり、どれもイマイチな所があって、手軽な方法が欲しいと思っていた。 何気なくcurlコマンドのオプションを調べていたら、「もうこれでAPIドキュメント扱いにしちゃえばいいんじゃね？」と思えてきたのでメモしておく。 curlコマンドのおさらい curlコマンドはlibcurlの付属コマンドで、最近のUnix系OSなら大抵最初から入っていると思う。コマンドの詳細はmanを読んでいただければ。 cURL - How To Use （マニュアルページ日本語訳） curlコマンドのオプシ
以前のエントリで調査したcurlのバージョンの違いについてその後色々調べたので結果をまとめてみる。 おさらい CentOS4系 curl 7.12 CentOS5系 curl 7.15 サーバの移行を行ったところ、curlの通信に著しい遅延が発生した。具体的に言うと1回の通信で2秒かかる。 前回の対策としてはとりあえずCentOS4系のSRPMを持ってきてビルドし、バージョンをダウングレードして対応した。 調査 実は前回のエントリでは環境を正確に書ききっていなかったorz。 今回調査を続けた結果以下の環境でのみこの2秒遅延が起こることが判明した。 環境 curl 7.13以降 POSTデータが1024バイト以上 Poundサーバ経由したときのみ 前回は単純にcurlのバージョンのみが問題だと思って色々調べたんだけど、他のサーバのログや環境を比較しているうちに上記の条件が確認できた。 確認し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
