Как получить HTTP 100 Продолжить работу для WebDAV на встроенном Grizzly?

Я использую сервер Milton WebDAV (1.6.8) со встроенным контейнером сервлетов Grizzly (2.1.7), и в их конфигурации по умолчанию запросы PUT (по крайней мере, выпущенные Cyberduck) не работают. Я отследил проблему до проблемы с обработкой HTTP 100 Continue (очевидно, это также влияет на Jetty), сообщение на список рассылки Milton и система отслеживания ошибок говорит, что это ошибка контейнера сервлета, который пытается быть умным с прозрачной обработкой ожидания/продолжения.

Да, контейнеры, которые прозрачно обрабатывают ожидания, продолжают эффективно нарушать безопасность HTTP для Webdav. HTTP использует модель безопасности запрос/ответ, и многие клиенты полагаются на нее. Т.е. при выполнении PUT они будут просто выполнять PUT без проверки подлинности и полагаться на ExpectContinue, чтобы гарантировать, что запрос будет выдан до того, как файл будет загружен.

Но с прозрачной обработкой ExpectContinue весь файл загружается до того, как milton API сможет проверить, аутентифицирован ли текущий пользователь и авторизован ли он для выполнения действия.

В зависимости от ваших поддерживаемых клиентов и вариантов использования это может быть либо совершенно неприемлемым, либо неприятным, либо вообще не проблемой.

Но, как правило, я думаю, вы должны попытаться выяснить, можно ли отключить прозрачную обработку Grizzly, а затем снова включить поддержку в milton.

Что я могу сделать, чтобы отключить прозрачную обработку ожидания/продолжения Grizzly, и действительно ли это правильный подход? Альтернативой может быть отключение обработки ожидания/продолжения в Milton, но это, похоже, нарушает аутентификацию WebDAV.

Обновление: я также попробовал Jetty сейчас (8.1.0.RC1), и он демонстрирует то же поведение, что и Grizzly: только с отключенной обработкой ожидания/продолжения я могу помещать файлы, с настройками по умолчанию он делает не работа.


http servlets grizzly webdav milton
person Thilo    schedule 05.12.2011    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Что касается 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;
        }
    }
}

Надеюсь, это поможет.

person alexey    schedule 13.12.2011
comment
Пробовал так, но не получилось. Также поставил точку останова, но она туда не пошла. Кто должен позвонить sendAcknowledgement и когда? Насколько я вижу, Милтон просто устанавливает код состояния SC_CONTINUE и завершает обработку запроса. - person Thilo; 13.12.2011
comment
завтра буду копать глубже, но пока кажется, что sendAcknowledgement вызывается не в моем ServletHandler, а в HttpHandlerChain. - person Thilo; 13.12.2011
comment
Пожалуйста. попробуйте последнюю версию Grizzly 2.1.8 - person alexey; 14.12.2011
comment
Теперь его вызывают. Клянусь, вчера не было 2.1.8 ;-). Но что такое authClient? - person Thilo; 14.12.2011
comment
мы только что выпустили 2.1.8 :) authClient() — это не что иное, как пример любой логики, которую вы можете там реализовать. - person alexey; 14.12.2011
comment
Есть ли какой-нибудь учебник о том, как это должно работать? Потому что sendAcknowledgment вызывается в результате моей логики аутентификации, которая отправляет 100-continue, чтобы предложить клиенту отправить дополнительную информацию. Будут ли в это время доступны продолжающиеся данные (т. е. заголовки аутентификации)? У меня сложилось впечатление, что сначала есть еще один кругосветный рейс. Конечно, может быть, я здесь что-то совсем не так понимаю. - person Thilo; 14.12.2011
comment
Жаль, что это специальное исправление для гризли, поскольку Jetty делает то же самое и (я думаю) tomcat. - person Brad at Kademi; 14.12.2011
comment
Thilo: другого обмена заголовками не будет, после получения 100-Continue клиент отправит только тело сообщения. Брэд: ты имеешь в виду, что это позор, что спецификация сервлета не распространяется на это? :) - person alexey; 14.12.2011
comment
@brad: Вы хотите сказать, что у Jetty и Tomcat такая же проблема (я только что попробовал Jetty 8.1.0.RC1, и, похоже, это так). Тогда какой контейнер сервлетов лучше работает с Milton? - person Thilo; 22.12.2011

arrow_upward
0
arrow_downward

Обратите внимание, что проблема с прозрачной обработкой ожидания-продолжения зависит от того, используют ли ваши целевые клиентские приложения проверку подлинности «ожидание-продолжение» или нет.

Я еще не исследовал это слишком подробно, поэтому не могу с уверенностью сказать, какие контейнеры выполняют прозрачную обработку и можно ли ее отключить или какие клиентские приложения требуют этого.

Было бы хорошо, если бы кто-нибудь из Grizzly или Tomcat мог прокомментировать варианты отключения обработки контейнеров.

person Brad at Kademi    schedule 08.12.2011
comment
Есть ли эталонный контейнер для Milton, в котором ожидание-продолжение работает «из коробки»? Мне не нужно использовать Grizzly, если я не могу заставить его работать. - person Thilo; 14.12.2011