1

次の 2 つの URL が同じ方法で処理されることを確認したいと思います (この方法でリクエストを送信する既存のクライアントがあります)。

/resource
//resource

残念ながら、両方の URL を同じルートに追加することはできず、この//resource形式を使用しようとしても、この場合は URL マッチングが正しく機能しません。

WSGI の前のサーバーでリクエストを書き換える必要がないように回避する方法はありますか?

編集: NewRequest イベントにアクセスできる pyramid.event を見つけたので、パスを書き換えることができると思いますが、さまざまな方法でパスを取得するさまざまな関数が多数あるため、正確にどのようにすればよいかわかりません既存のリクエストでそれを書き換えます。

edit2: イベント全体に関する情報が//resourceなくなったようです - 照会した要素にはそれが表示されません。すべてが、私が のリクエストを受け取ったと主張してい/ます。

edit3: 実際には、Pyramid 自体ではなく、貼り付けまたは間にある他のモジュールに関連しているようです - uwsgi は元の path_info を二重スラッシュで問題なく渡します。

4

2 に答える 2

0

これは、便利な回答があるこの質問の複製のようです。

基本的に二重スラッシュは WSGI ではサポートされていないため、Pyramid ではサポートされていません。

于 2014-09-15T11:03:54.447 に答える
0 
import re

class RemoveDoubleSlashes(object):
    def __init__(self, application):
        self.application = application

    def __call__(self, environ, start_response):

        environ['PATH_INFO'] = re.sub('/+', '/', environ['PATH_INFO'])                                                                                                                      

        return self.application(environ, start_response)

メインの最後に：

return RemoveDoubleSlashes(config.make_wsgi_app())

リクエストごとに正規表現の置換を行うのがどれほど難しいかはわかりませんが、本当に必要な場合はうまくいきます。

編集

これは、ピラミッドに到達する前に PATH_INFO を編集する方法であることに注意してください。あなたはそれをすべきではありません。有効な URL を作成し、間違った URL が失敗するようにする必要があります。

アプリで誤って作成された URL を修正する方法が見つかるまでは、応急処置として使用する必要があります。このミドルウェアは治療法ではなく、単なるパッチです。すべての URL でスラッシュの繰り返しをチェックしても意味がありません。

質問を読み直すだけで、正規表現を使用する代わりに二重スラッシュで始まるかどうかをテストできます。replace('//', '/')そして、PATH_INFO が二重スラッシュで始まる場合は単純です。

正規表現は、「//fdf//3dfdf/」のようなものがあるだけで意味があります

于 2012-07-16T20:17:03.270 に答える