> Предохраняться конечно же нужно.

А я то думал что надо уповать на сферический софт в вакууме, в котором багов не бывает.

> Что не отменяет безумности подхода копипаста текста из http запроса в запрос к БД.

В этом месте я могу вернуть ваши слова и заявить что хорошая БД не хуже хорошего сервера и не должна вестись на фигню. Некоторые key-value даже сожрут произвольный URL как key и не возымеют от этого проблем. Однако один и тот же URL можно представить довольно большим числом разных способов - потому что стандарт так написан - так что даже так можно откушать приколов. Конечно можно порассуждать о библах и всем таком. Но таки - приколы такого плана были и есть. И рядом - тоже. Типа вон тех request smuggling когда манипуляцией с запросом реквест подшивается к вообще кому-то постороннему. Например потому что фронт и бэк парсят немного по разному.

А запрос к базе на реквест статики таки булшит и RPS угрохает. Так что "докупите серверов".

> Как бы речь о том и идет. Что нужно как бы проверять
> то что клиент из Индии прислал в запросе.

Да никто не спорит что нужно - но тут вообще документированное поведение было так то. То что оно не лучшее на свете и ведет к ололо - ну, окей, допустим.

> Безобразие.

Но вон там это вообще фичой было. Просто довольно неожиданной для некоторых.

> Интересный.

Авторы нжинкса вообще местами странноватые вещи делали. Однако остальные делают не менее странные вещи. А иногда и более. Если так посмотреть, на глупые грабли встают практически все HTTP серваки. Сочетание семантики ФС с структурой контента и запросов это такое сочетание которое вообще довольно трудно реализовать секурно во всех позах. Особенно если еще наставить фронтов, бэков, в потом окажется что они одно и то же немного по разному понимают, ...

На мой вкус я б фильтровал ../ как элемент путей в (уже декодированых) урлах - но контент тогда сломается много где.