LINUX.ORG.RU

Принудительно завершить обработку multipart запроса на 7ом томкате в сервлете

 , , ,


0

1

Вчера воткнулся в дурацкую проблему, такое ощущение что при посте в сервлет файла, этот запрос дополнительно перехватывается каким-то фильтром (видимо это тот, который проверяет его размер) и если мне приспичило в момент чтения файла в сервлете вернуть клиенту отказ (например место кончилось и некуда его положить), то сделать этого я не могу. Не помогает даже кидание эксепшенов. Файло с клиента продолжает упорно течь, т.к. засирания памяти нет, то предполагаю что, что-то тупо перебирает байтики.

Сильно не нравится то, что если сеть медленная то клиент узнает о проблеме слишком поздно, ну и занятая сеть тоже не есть гуд. Кто-нибудь сталкивался?

ПС: почему-то мне кажется что в 6м такого не было.

★★★★★

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

maxcom ★★★★★
()

HTTP это поток. По идее закрытие потока должно прекращать передачу. в tomcat 6 работало закрытие и выставление

response.sendError(HttpServletResponse.SC_REQUEST_ENTITY_TOO_LARGE, "Error"); 

в 7 не знаю будет ли это работать. Срач по данному поводу можно почитать тут

http://markmail.org/thread/qpdza5qz4ziigkx5#query: page:1 mid:c4qo4g2wc4sm7g5...

vtVitus ★★★★★
()
Ответ на: комментарий от vtVitus

HTTP это поток. По идее закрытие потока должно прекращать передачу.

Спасибо, Кэп. Вот бы знать ещё как его закрыть то, ибо выход из doPost у меня в сервлете происходит раньше, чем данные полностью приползают на сервак.

в tomcat 6 работало закрытие и выставление

Вот и сам помню что вроде бы работало.

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

Вроде бы же даже в стандарт запиливали ранние ответы, только не помню гуглибельное название.

ya-betmen ★★★★★
() автор топика
Последнее исправление: ya-betmen (всего исправлений: 1)
Ответ на: комментарий от ya-betmen

Как-то так, код стянул давно из инета

try { 
   request.getInputStream().close(); 
} catch(IOException ignore) {}

try {   
    response.sendError(HttpServletResponse.SC_REQUEST_ENTITY_TOO_LARGE, "Error"); 
    response.flushBuffer(); 
}catch(IOException ignore) {}

try { 
    response.getOutputStream().close(); 
} catch (IOException e) {} 

но 500 код в через sendError

Нет именно TOO_LARGE.

Вроде бы же даже в стандарт запиливали ранние ответы, только не помню гуглибельное название.

Самое простое, сервер передаёт максимальные размер файла, который он готов принять и через file api идет проверка в javascript.

vtVitus ★★★★★
()
Последнее исправление: vtVitus (всего исправлений: 1)
Ответ на: комментарий от vtVitus

Как-то так, код стянул давно из инета

Ура! Заработало, спасибо.

Самое простое, сервер передаёт максимальные размер файла, который он готов принять и через file api идет проверка в javascript.

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

Хм, это на 8ом заработало, 7ого на работе нет, проверю дома, но в любом случае у меня есть рабочий вариант для 6 и 8. 7ой, если что, можно будет проигнорировать.

ya-betmen ★★★★★
() автор топика
Последнее исправление: ya-betmen (всего исправлений: 2)
Ответ на: комментарий от ya-betmen

Хм, это на 8ом заработало, 7ого на работе нет, проверю дома, но в любом случае у меня есть рабочий вариант для 6 и 8. 7ой, если что, можно будет проигнорировать.

Так и есть, в 8ом работает в 7ом нет. В 8ом достаточно выплюнуть ошибку до того как подёргал входной поток. В 7ом вообще без вариантов, остановить запрос не выходит никаким способом.

ya-betmen ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.