Покидал куски своих статей с хабра.То что проиндексировано считает живым текстом (соотвественно выдаёт ссылку).То что давно в черновиках и остутствует в поиске считает генерёнкой.Учитывая, что стилистика/авторство текстов неизменно, то как будто основывается на критерии нахождения в поиске...
что собственно и подтвердилось
пример с return - это очень упрощённая ситуация, в реальности мы же работаем не с просто return 200 "bu", а делаем append модуля (например для прямых запросов к БД), который работает минуя http фазу, где после append() вся обработка уходит в nginx event loop, что очень дёшево. Но здесь, если мы хотим всё-же иметь возможность делать limit_req, нам придётся пожертвовать дешевизной и делать append() аж в CONTENT_PHASE, что может свести на ноль саму идею прямых запросов.
разумеется разная - 200-й ответ мы можем отдать ещё в REWRITE_PHASE, а для отдачи 503 нам придётся подняться аж до PRECONTENT_PHASE, чтобы обработать директиву error_page 404 = @named_loc, опуститься обратно ,запустить счётчик limit_req и пока он не достигнет превышения мы будем отдавать 200-ю и гонять его по этому циклу и только потом отдадим 503-и код ответа.
для этого и надо изначально понимать на какой фазе "живёт" требуемый модуль.
С сёрф энд тёрф? 😊- пример того как кажущаяся внешняя эффектность подменяет кулинарную логику
С документацией nginx? - в ней есть ошибки, например, директива try_files по-прежнему описана в ngx_http_core_module
С непониманием работы nginx? - в высоконагруженных системах мы пытаемся отдать контент как можно раньше и самое раннее где мы можем его отдать - это ngx_http_rewrite_module, соотвественно в фазах SERVER_REWRITE_PHASE/REWRITE_PHASE, и если мы это делаем, то модули навешиваемые в следующих фазах уже не будут задействованы.Из примера ранее - мы теряем возможность сделать limit_* , так как его модули обрабатываются в PREACCESS_PHASE, при этом (опять же из-за того, что это явно не указано в документации) так делают повсеместно.
Причём это не ляп документации, это именно её системное непонимание системно и постоянно воспроизводимое.
И на основе этой системности мы и будем обучать нашу систему
соотвественно мы всегда будем получать "Surf and turf"
Всегда, именно такую он и предложит.
Вы просто не учитываете хронологию возникновения этой ошибки. Это не вопрос с собесов, это более чем системная ошибка.
1) Сначала у нас возникает локейшин, в котором мы делаем заглушку "return XXX"
2) туда летит DDoS
2a) мы даём задачу клуади
3) мы его глушим именно этим некорректным кодом (причём согласно документации) limit_req
Я привожу пример именно на основе nginx, ибо мне так проще, но я могу доказать и на основе глубуко C-шных примеров, хотя в рамкках этого форума это слишком скучно
ну совбственно, почему и как про Nginx я писал лет 5 назадhttps://habr.com/ru/articles/561758/https://habr.com/ru/articles/567418/
и это я уже 10+ лет не админ...сколько накидает vbart или dunin я даже не представляю близко
чем дообучать будем? я ведь не спроста вкинул хоть и элементраные запросы, но те, которые1) не окучены в man'е
2) код которых в массе содержит данную ошибку в 90%+ случаев.
по итогу мы всегда будем обучать систему ошибочными решениями и, соответствено, получать то, что имеем
