Apache がロケーション セクションを統合 (再び)

Apache がロケーション セクションを統合 (再び)

私は読むこの答え以前、同様の質問がありましたが、その回答は理にかなっていて、Apache 2.4 のドキュメントと一致していました。しかし、次のような経験があり、その回答とドキュメントに矛盾しているようです。次のディレクティブを検討してください。

<Directory "/opt/lampp/htdocs/foo">
    AuthName "foo user"
    AuthType Basic
    Authuserfile /opt/lampp/passwds/foo.users
</Directory>
<VirtualHost *:80>
    ServerName   foo.example.com
    DocumentRoot "/opt/lampp/htdocs/foo/public"
    ErrorLog     "logs/foo.error_log"
    <Location />
        Require valid-user
    </Location>
    <Location /wp/feed>
        Require all granted
    </Location>
    CustomLog    "logs/foo.access_log" combined
</VirtualHost>

明らかに、その目的はすべてのURLをHTTP基本認証で保護することです。を除外する下記の URL に対して です/wp/feed。しかし、Apache をリロードした後、 に行くときに認証情報の入力を求められました/wp/feed。その URL は両方の Location パスに一致するため、Apache はRequire valid-userに続いてを処理するはずでありRequire all granted、プロンプトは表示されないはずです。「楽しみ」のために、ロケーション ブロックの順序を入れ替えてみましたが、それでもプロンプトが表示されました。意図したとおりに機能する唯一の方法は、"/" のロケーション ブロックを完全に削除することでした。私にとっては、これも予期しない動作でした。なぜなら、その場合、 にRequire valid-user一致しない URL に適用されるはずのディレクティブがまったくなかったからです。/wp/feedしかし、 に一致しないすべての URL に対してプロンプトが表示されたことを考えると、それらは適用されました。/wp/feed

誰かこれを説明できますか?私は答えを理解するのに時間がかかりすぎているのでしょうか?ドキュメンテーション?

最長のプレフィックス一致が一般的に優先される nginx ディレクティブを使用してこの動作を指定することに問題はありませんでした。私が得た動作が本当に期待通りの動作である場合、Apache で望む動作を得るにはどうすればよいのでしょうか?

関連情報