WerkzeugとFlaskを使用してRESTAPIを構築しています。 このコンテキストでは、末尾のスラッシュを追加する自動動作は望ましくありません。これは、GETと他の要求の間の非対称性につながるため、ここでは厳密にすることが許容されます。
現在、これを行うには、内部( Rule.match
およびRequestSlash
)にフックするカスタムルールクラスを使用する必要があります。
これを一次構成オプションとして追加するのは理にかなっていますか? URLマップのappend_slash
(同等のDjangoオプションと並行するため)のようなものですか?
app.url_map.strict_slashes = False
は、これを回避するために必要なすべてです。
これにより、スラッシュが欠落している場合に実際にルートが一致します。 404にしたいです。
現在の動作は次のとおりです。
| ルールの末尾にスラッシュがあります| パスの末尾にスラッシュがあります| strict_slashes
| 結果|
|-|-|-|-|
| N | N | True
| (一致)|
| N | N | False
| (一致)|
| N | Y | True
| 404 |
| N | Y | False
| 404 |
| Y | N | True
| 301 |
| Y | N | False
| (一致)|
| Y | Y | True
| (一致)|
| Y | Y | False
| (一致)|
ルールの末尾にスラッシュがあるのにパスにない場合は、404が必要です。 現在、私はこれを次の方法で行っています。
class StrictRule(Rule):
def match(self, path, method=None):
try:
result = super(StrictRule, self).match(path, method)
except RequestSlash:
return None
return result
しかし、私はむしろ内部に手を差し伸べたくありません。
カスタムルールを使用することは、Flaskでこれを行う正しい方法です。 私たちは、ルール内のすべての人のためにすべてを作成しようとしないことを社内で決定しました。 標準で提供されているものを超えるルールが必要な場合は、それを指定する必要があります。 Flashの場合、 url_rule_class
を新しいクラスに設定します。 詳細については、Flaskのドキュメントを参照してください。 http://flask.pocoo.org/docs/1.0/api/?highlight=rule#flask.Flask.url_rule_class
@aenglander
https://github.com/pallets/werkzeug/issues/1246#issuecomment -362099342によると、ここでの問題はカスタムルールの実装にあります。 RequestSlash
は、 https: //github.com/pallets/werkzeug/blob/a220671d66755a94630a212378754bb432811158/src/werkzeug/routing.py#L259 -L260に従って、内部例外として明示的にマークされているため、これを処理するのは非常に厄介です。ユーザーコード。
基本ルールがすべての可能なユースケースをサポートするわけではないことには確かに同意しますが、末尾のスラッシュがない場合に一致しないことは非常に一般的なユースケースです。 従来技術の場合、このパターンはAPPEND_SLASH
介してDjango構成で明示的に公開されている数少ないパターンの1つです: https ://docs.djangoproject.com/en/dev/ref/settings/#append-slash。
この場合の「内部」とは、「内部使用のみ」ではなく「内部処理」を意味します。表示されているコードは問題なく使用できます。
@davidism説明ありがとうございます。 それでは、先に進んでこれを実行します。
最も参考になるコメント
app.url_map.strict_slashes = False
は、これを回避するために必要なすべてです。