LINUX.ORG.RU

POST файлов на веб-сервер. Разорвать коннект, не дожидаясь конца передачи.


0

1

Из-за проксей, не поддерживающих HTTP 100 (этот «Expect: 100-continue»), я не могу включать этот заголовок в POST-запрос, следовательно приходится делать один POST-запрос сразу со всем содержимым.

Как в таком случае защититься на сервере от POST со стороны злоумышленника, у которого нет правильного sid? Как можно на сервере в 2-х вариантах php или CGI (FastCGI/C++) разорвать соединение ещё до окончания передачи всех данных (которых мож.быть много)?

Файлы будут поститься на URI http://..../?sid=81728172. Мне нужно порвать соединение, если sid в запросе отличен от заданного. Да, такие вот запросы одновременно с GET и POST-данными, хотя наверное это php-шная терминология, а "?sid=123" - это часть URI под CGI-названием QUERY_STRING.

В PHP шарю плохо, но вроде бы там при передаче управления в скрипт уже доступна вся информация по запросу, т.е. запрос уже целиком пришёл, то есть сервер уже принял все вложенные в POST файлы и положил во временный каталог, даже если они были неизвестно от кого. Как с помощью PHP рвать соединение неизвестно от кого и без HTTP 100? Если в PHP это невозможно, то возможно ли в FastCGI / C++? Предпочтительнее второе, но если можно на PHP, то как временное решение сойдёт.

То есть я хочу такого поведения: злой хакер постит гигабайтный файл, на сервер успевает падать килобайт 100, на которые хакер получает TCP ACK (из-за буфферизации и быстрых каналов), параллельно с этим FastCGI-приложение читает строку запроса и понимает, что соединение надо рвать, отправляет какой-нибудь «HTTP 400» и желательно закрывает коннект, чтобы клиент больше не получал никаких TCP ACK на данные, которые продолжают с него литься).

Кстати, как отработает веб-сервер, если FastCGI уже «всё понял» и выдал веб-серверу ответ для клиента, а с клиента продолжает литься продолжение файла, который он постит? Это будет «исключение» на уровне HTTP и будет закрыт уровень TCP? Или может попасться такой веб-сервер, который пока не дождётся прихода полного запроса не будет слушать ответы от FastCGI-стороны? (юзаю nginx)

Наверное можно этот sid запихать в «POST-параметры», но это фиолетово.

Спасибо.

Перемещено Pi из Development

★☆

Последнее исправление: kiverattes (всего исправлений: 2)

>параллельно с этим FastCGI-приложение читает строку запроса и понимает, что соединение надо рвать, отправляет какой-нибудь «HTTP 400» и желательно закрывает коннект, чтобы клиент больше не получал никаких TCP ACK на данные, которые продолжают с него литься).

Насколько я помню спецификацию FastCGI — сначала приходит FCGI_BEGIN_REQUEST, затем FCGI_PARAMS, а только потом идет FCGI_STDIN. Причем приложение не обязановы вчитывать весь FCGI_STDIN перед началом обработки запроса.

Т.е. тупо получив все FCGI_PARAMS смотришь кошерный у тебя запрос или нет, и если не кошерный — даешь FCGI_END_REQUEST с заветным 400 кодом. Единственное в чем надо удостовериться — что твой фронтенд в такой ситуации нормально пришибет клиентское соединение. Nginx, емнип, такое обрабатывал на-ура.

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