20:34Unix上でオープンソースとして育ってきたツールの多くは特にかっちりした「仕様」なんてないままas-isで提供されているものが殆どです。公式サイトがある場合でも、「ドキュメント」=「manページ」であることが多々で、manページ以上のものは得られないことも多くあります。(curlもそのように見えます。)後は開発者グループが現在の挙動を意図的にそう実装しているのかどうかですが、公式サイトを見てもmetropolisさんご紹介のソースのコメントを見てもよくわかりませんでした。誰かが、「現在の挙動はおかしい、バグじゃないか」とバグ報告を上げたら修正されるかもしれません。過去にバグ報告が上がっていて、「バグじゃない」と結論づけられているかもしれません。(libcurlのメーリングリストには「実際のリクエストにはfragment部分が含まれない(ので困る)」なんてのがありましたが。)「curlの独自機能」と言うよりは「curlの現在の実装」と言うことになると思います。言うわけで、タイトルに「正当性」とありますが、何を持って「正当」とするのかわからないと、「回答」としては書けないですね。22:192curlのソース該当箇所はこちらですね。2.1)からはlibcurlを利用しなくなったらしく?、これがバージョン間挙動の差異として現れているのかも知れません。動作に問題が無い範囲で簡略化することが多いです。この質問でのcurlの動作も、「/で分割した最後をファイル名として扱う」辺りの「割り切り」じゃないかなという気がします。票3せっかく私のコメントに関して追記していただいているので、無理にでも回答を書いてみるとこんな感じ。記されているが、構文規則にはfragmentとだけ書いてある)で、URIとしては構文上正しいものです。この例で言うとURIのPath部分がcurl-7.61.1.tar.bz2.ascまでになることはURIの仕様として規定されています。(ちなみに上の_Fragment_のリンクの中身はhttps://tools.ietf.org/html/rfc3986#section-3.5と言うもので、この場合、https://tools.ietf.org/html/rfc3986で表される文書の中でsection-3.5と言う識別子で表される特別の部分を表す書き方です。)通常の使い方では#/custom-named-fileの部分はサーバ側には送られないか、サーバ側では無視され、受信したリソース(今の場合はHTMLテキスト)のどの部分かを特定するのにブラウザ側で使われます。上記のRFC自体はFragmentの詳細な意味までは定めていないので、クライアント側がFragment部分を送信するかどうか、サーバ側が受信したFragmentをどう解釈するかは、使用するクライアント・サーバによります。(この辺り詳細な規定があるのか調べきれていません。)従って、使用するクライアント・サーバによっては、Fragmentの有無で取得されるリソースが変わってくる可能性があります。curlの場合には(少なくともHTTPであれば)Fragment部分は送信しないようなので、この心配はなさそうです。fileを表すと言う規定は(HTTP以外を探しても)存在しないでしょう。これは何か公の仕様に則った挙動なのでしょうかコメントに書いたようにcurlの場合、「公の仕様」と言えるものはmanページくらいしかありません。現在のcurlの-Oオプションの記述はこうなっています。fileとする」という風に解釈するのは、無理でしょう。(もちろん明確にそうしない、とも取れない。)つまり「何か公の仕様に則った挙動」とは言えない、と言うことになると思います。curlの独自機能なのでしょうかこれもコメントどおりですが、現在の挙動が意図されたものかどうかがわかるような記述は見つけられませんでした。(数分間公式サイトをうろうろしただけですが。)と言うわけで、(意図して提供されている)「独自機能」と言うよりは、「現在の実装ではそうなる」と言うことだと思われます。Web系開発者から見て、curlの今回の挙動は、当然そうなるだろうというものなのか、いやいやおかしいだろうというものなのかすでに上に述べたことでわかると思いますが、「当然そうなるだろう」と期待する根拠は「現在の実装がそうなっている」こと以外にはありません。「いやいやおかしいだろう」と言うものかどうかは人によるだろうと思います。(世間に流通しているシェルスクリプトなんかには、いろんなコマンドの「現在の実装」に基づく詳細動作に依存しているものはいっぱいあるでしょう。)結論としては、ご自身で書かれているように「(現在の)curlのurlパース仕様を利用したハック技」と言えるだろうと思います。(ただ、便利ツールであるcurlが、「こんなのバグじゃないの?」なんて指摘を受けても、そこの実装が変更される可能性は低いと思いますが。)私的には、curlには、ちゃんと出力先を示す-oオプション(わかっているとは思いますが、小文字の方です)があるんだから、素性のわからない-Oと#/nameなんて書き方を使わなくてもいいんじゃないの?と言う感じです。http://localhost/hello#fragmentはfragmentが取り除かれた状態でGETしています(この挙動は、ウェブブラウザやcurlと同等なようです)。入力された文字列そのまま、fragment付きでGETします。Request)を返しているようで、結果として記載しているような応答の差異になって表れているようです。PowerShellにおけるこの挙動の差異が仕様変更によるものなのかは未調査です(バグの可能性もあります)。Coreに対する修正です。Resourceが挙げられていました。あとは、Sec5.3(特にSec5.3.1)も合わせて見ると分かりやすいのかな、と思いました。ここでは一切fragmentが登場しません。OOPerさんの回答では上記のRFC自体はFragmentの詳細な意味までは定めていないので、クライアント側がFragment部分を送信するかどうか、サーバ側が受信したFragmentをどう解釈するかは、使用するクライアント・サーバによります。(この辺り詳細な規定があるのか調べきれていません。)と書かれていらっしゃいますが、このRFC7230を見た感じでは、サーバにはfragmentを投げてはいけない、が正解なのかな、と思われました。Request)を返していると書きましたが、こちらのコメントでは404を返す、と書かれており、fragmentを受け取った場合の挙動はサーバ実装依存となっているようです。|回答スタック・オーバーフローに参加してくれて、ありがとうございます!質問の回答を共有してください。回答を説明し、自分の検討結果も共有してください。意見を述べること(意見を述べるなら、参照リソース、自分の経験で意見をサポートしてください)さらにサポートが必要な場合このヘルプを参考してください。“回答を投稿”をクリックすることで利用規約、プライバシーポリシー、及びクッキーポリシーに同意したものとみなされます。タグが付いた他の質問を参照するか、自分で質問をする。質問のフィードこのRSSフィードを購読するには、このURLをコピーしてRSSリーダーに貼り付けてください。