1

Grizzly サーブレット コンテナー (2.1.7) が組み込まれた Milton WebDAV サーバー (1.6.8) を使用していますが、デフォルトの構成では、PUT 要求 (少なくとも Cyber​​duck によって発行されたもの) が機能しません。私はこの問題を HTTP 100 Continue の処理方法に関する問題 (Jetty にも影響しているようです) まで追跡しました。Milton メーリング リストとバグ トラッカーのメッセージによると、これはサーブレット コンテナーのせいであり、巧妙になろうとしています。 「透過的期待/継続処理」。

はい、透過的に処理するコンテナーは、引き続き期待を処理し、Webdav の HTTP セキュリティを効果的に破ります。HTTP はチャレンジ/レスポンス セキュリティ モデルを使用しており、多くのクライアントはそれに依存しています。つまり、PUT を実行する場合、認証されていない PUT を実行し、ExpectContinue に依存して、ファイルがアップロードされる前にチャレンジが発行されるようにします。

しかし、ExpectContinue の透過的な処理では、ミルトン API が現在のユーザーが認証され、アクションを実行する権限があるかどうかを確認できるようになる前に、ファイル全体がアップロードされます。

サポートされているクライアントとユースケースに応じて、これはまったく受け入れられないか、迷惑になるか、まったく問題にならないかのいずれかになります。

しかし、一般的には、Grizzly の透過的な処理を無効にできるかどうかを調べてから、milton でサポートを再度有効にする必要があると思います。

Grizzly の透過的な期待/継続処理を無効にするにはどうすればよいですか?これは本当に正しいアプローチですか? 別の方法として、Milton での expect/continue 処理をオフにすることもできますが、それでは WebDAV 認証が壊れてしまうようです。

更新:今も Jetty (8.1.0.RC1) を試してみましたが、Grizzly と同じ動作を示します。expect/continue 処理がオフになっている場合にのみファイルを PUT できます。デフォルト設定では機能しません。

4

2 に答える 2

1

Grizly 2.x に関しては、次のようにsendAcknowledgmentメソッドをオーバーライドする必要があります。ServletHandler

class MyServletHandler extends ServletHandler
{
    protected boolean sendAcknowledgment(final Request request,
        final Response response)
        throws IOException
    {
        if (authClient(request, response)
        {
            return super.sendAcknowledgment(request, response);
        }
        else
        {
            response.setStatus(HttpStatus.EXPECTATION_FAILED_417);
            return false;
        }
    }
}

それが役立つことを願っています。

于 2011-12-13T09:52:09.783 に答える
0

透過的な期待継続処理が問題になるかどうかは、対象のクライアント アプリケーションが期待継続認証を使用するかどうかによって異なります。

これについてはまだ詳しく調査していないため、どのコンテナが透過的な処理を行うのか、それを無効にできるかどうか、どのクライアント アプリケーションがそれを必要とするのかについて、はっきりとは言えません。

Grizzly または Tomcat の誰かが、コンテナーの処理を無効にするオプションについてコメントしてくれれば、良いかもしれません。

于 2011-12-08T01:52:56.170 に答える