HN 日本語サマリー

← 一覧へ戻る
プログラミング

Curlese、5年後の考察

Curlese, Five Years Later (hypertesto.me)

7 pointsby rovr1382 コメント

要約

この記事は、HTTP連携の問題解決にcurlコマンドを活用する「Curlese」という手法について、5年前の提唱から現在までの進化を考察しています。HTTP/2やmTLSの普及、WAFやAPIゲートウェイの増加といった技術的変化に対応するため、curlコマンドの新たな活用法や便利なオプションが紹介されています。また、AIによる分析への応用にも触れ、curlコマンドが問題解決の普遍的なツールであり続けることを示唆しています。

全文翻訳

目次 約5年前に、HTTP連携がうまくいかず、どちらに問題があるかを突き止める必要がある場合に、curlを普遍的な言語として使うという、私が冗談で「curlese」と呼んだことについての投稿(イタリア語)を書きました。 そのアイデアはシンプルでした。相手が読みたがらないログファイルについてプロバイダーと議論する代わりに、curlコマンドを送るのです。それは自己記述的で、再現性があり、そして最も重要なことに、それはあなたのコードではないため、「あなたのアプリケーションがバグっている」と却下されることはありません。 5年後、この仮説が驚くほど有効であり続けたことを確認できます。私は今でも頻繁にこれを行っています。しかし、この仮説を取り巻く世界はかなり変化したので、更新の時期が来ました。何が変わり、何が変わらず、そして2026年における私のサバイバルキットはどのようなものかを見ていきましょう。 変わらなかったこと # 社会的な問題は、私がそれを置いたまさにその場所にあります。すべての連携には、少なくとも2つのチーム、誰も完全に理解していないファイアウォール、そして「私の側では動いています」という会話から始まるやり取りが依然として伴います。あなたの明確なアプリケーションログは、その会話では依然として価値がありません。なぜなら: 相手側はあなたのログを解釈できない(または解釈したがらない) 問題があなたにあると仮定する方が常に簡単である 実際に修正できる人に話しかけていることはめったにない 出力付きのcurlコマンドは、これら3つの問題をすべて解決します。それは実行可能な証拠です。チケットに貼り付けることができ、相手チームのネットワーク管理者はそのまま実行できます。そして、その判断はプレーンテキストで書かれます。この投稿のこの部分はまったく更新の必要がありません。これは、あなたの気分によって、安心できるか、あるいは憂鬱になるかのどちらかです。 変わったこと # 実際、かなり変わりました。 HTTP/2はどこにでもあり、HTTP/3はもはや珍しくありません。2021年には、私が扱う種類の連携ではプレーンなHTTP/1.1交換が標準でした。今では、HTTP/2をネゴシエートするエンドポイントに定期的に遭遇し、ALPN自体が問題の一部である場合もあります。あなたのラップトップからはリクエストが機能するのに、サーバーからはハングする場合、「彼らが異なるHTTPバージョンを話している」というのが、今では正当な疑いとなっています。 mTLSは珍しいものから日常的なものになりました。クライアント証明書は、かつては年に一度の面倒なものでした。今では、B2B連携の半分が相互TLSを要求しており、これは私の2021年の自分ではカバーしていなかった、まったく新しいカテゴリの障害(およびcurlフラグ)を意味します。 すべてがWAF、プロキシ、またはAPIゲートウェイの後ろにあります。つまり、あなたが受け取るエラーは、アプリケーションからではなく、その前にいるドアマンからのものであることが多く、そのドアマンは、どのUser-Agent文字列が存在するに値するかについて独自の考えを持っています。私はかつて、あるエンドポイントが機能することを証明するのに午後を費やしました。相手側のエッジが特定のクライアントを気に入らなかっただけでした。修正は文字通りヘッダーを変更することでした。証明は、いつものように、1つのフラグが異なる一対のcurlコマンドでした。 共通言語には新しい話し相手ができました。2026年、あなたが問題を説明している相手は、人間であることがますます少なくなっています。LLMで行き詰まったときに貼り付けるのに最適なのは、-v出力付きのcurlコマンドです。それは、セットアップなしで、完全で曖昧さのないコンテキストです。チケットに理想的なのと同じ特性が、プロンプトにも理想的であることがわかりました。機械もcurleseを話します。 2026年のサバイバルキット # 古い投稿のすべてが依然として適用されます(-v、-k、--connect-timeout、--trace-ascii、--trace-time — 後者は数ヶ月前に幽霊のような遅延を追跡しているときに私を救いました)。ここでは、それ以来、永久的な場所を獲得したものを紹介します: フラグ なぜキットに入っているのか -w '%{time_total} %{time_connect} %{time_appconnect}' タイミングの内訳。「あなたのサーバーが遅い」と「あなたのTLSハンドシェイクが遅い」の違いは、どこにも行かないチケットと修正されるチケットの違いです。 --resolve host:port:ip 正しいSNI/Hostを使用して特定のIPをテストし、DNSをバイパスします。DNSがロードバランシングされており、一部のバックエンドのみが破損している場合に不可欠です。 --connect-to ::alt-host: 同じファミリー:ヘッダーをそのまま保持しながら、接続を別の場所にリダイレクトします。本番URLでステージングバックエンドをテストするのに最適です。 --cert client.pem --key client.key mTLS。障害の半分は証明書チェーンであり、curlは送信した証明書とサーバーがそれについて言ったことを正確に教えてくれます。 --json Content-Type: application/jsonを設定し、データをPOSTします。小さなことですが、「ヘッダーを忘れた」というクラスのエラーを、再現コマンドを作成する際に削除します。 --fail-with-body 終了コードはHTTPステータスを反映しますが、エラー応答ボディは引き続き表示されます。スクリプトにも人間にも最適です。 --retry 5 --retry-all-errors 「時々失敗する」は、もはや許容できるバグレポートではありません。統計に語らせましょう。 --no-alpn HTTPバージョンネゴシエーション自体が問題であると疑う特別な午後のために。まれですが、必要なときは、他に何もできません。 -wについての注意:フォーマット文字列は完全にカスタマイズ可能で、ひどく過小評価されています。curl -o /dev/null -s -w 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} total:%{time_total} http:%{http_code}\n' https://example.com は、任意の Сエンドポイントの1行パフォーマンス解剖を提供します。私はこれをシェルエイリアスとして持っています。あなたもそうすべきです。 辞書、更新 # 古い投稿には、頻繁なエラーメッセージとその通常の原因のリストがありました。ここに2026年版があります。同じ形式で、症状が先、可能性のある原因が後です: 症状 意味するところ 接続タイムアウト ネットワークパスなし。ファイアウォール、ルーティング、またはサービスがダウンしています。依然としてナンバーワンのヒットです。 接続拒否 パスは存在しますが、そのポートで何もリッスンしていません。サービスダウンまたはポートが間違っています。 SSL証明書の問題:ローカル発行者の証明書を取得できません 自己署名証明書、または信頼ストアが知らないCA。古典的で永遠です。 SSLv3アラートハンドシェイク失敗 / curl: (35) TLSバージョンまたは暗号スイートがオーバーラップしません。多くの場合、最新のクライアントに遭遇した古いサーバー、またはその逆です。 バージョン番号が間違っています プレーンHTTPポートにTLSで話しかけています。または、途中でプロキシが何かを改変しています。 HTTP/2ストリームエラー/リセットが--http1.1で消える ミドルボックスまたはバグのあるHTTP/2実装を持つサーバー。誰かを非難する前にダウングレードして再テストしてください。 聞いたことのない製品からのHTMLページでの403 それはWAFです。ページを読んでください。通常、ベンダーの名前が記載されており、どのエッジがあなたをブロックしているかがわかります。 --insecure では機能するが、そうでない場合は機能しない 証明書チェーンの問題。どこを掘り下げるべきかが正確にわかりました。 広める、リロード # 古い投稿は、相手にcurlセッションを要求するためのフレーズのリストで締めくくられました。それらは当時翻訳不可能であり、今でも翻訳不可能なので、ここに2026年の英語スターターパックがあります: 「あなたの側からcurlして、チケットに出力を貼り付けてもらえますか?」 「二人とも同じコマンドを実行して、結果を比較しましょう。」 「Postmanのスクリーンショットではなく、-vの出力を送ってください。」 「自分でcurlするか、私があなたをめちゃくちゃcurlします。」 5年経っても、私のアドバイスは変わりません。連携が壊れたら、議論するな、curlしろ!コマンドは契約であり、出力は判決であり、チケットは自己解決します。いくつかのテクノロジーは来たり行ったりしますが、謙虚なcurl呼び出しは、明らかに永遠です。 読んでくれてありがとう。そして今、言葉を広めに行きましょう! 元の投稿はここにあります。イタリア語を読む場合。Curleseは実際には翻訳されません。「curl」を言語名に変えたもので、curlareのような動詞やcurlataのような名詞(通常は怒って実行される単一のcurl呼び出し)があります。↩︎ それはcurlopsy(curl + autopsy)と呼ばれます。はい、ひどい名前です。いいえ、変更しません。2台のラップトップを乗り越え、この時点ではシニアです。↩︎ Postmanに反対するわけではありません。しかし、GUIのスクリーンショットは再現可能なテストケースではなく、あなたはそれを知っています。↩︎ 配信が重要です。無表情に、書面で、そして少なくとも1つのインシデントブリッジを一緒に乗り越えた相手とだけ。人事部はcurleseに堪能でないことで有名です。↩︎ はい、動詞です。イタリア語のオリジナルは「diffondete il verbo!」で締めくくられましたが、イタリア語ではverboは「言葉」と「動詞」の両方を意味するため、唯一正しい翻訳となります。curlは今や動詞であり、誇りを持って活用してください。↩︎