пример с 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%+ случаев.
по итогу мы всегда будем обучать систему ошибочными решениями и, соответствено, получать то, что имеем
именно та ошибка, которая и ожидаласьдиректива return ВСЕГДА будет выполняться до limit_req, потому что return в фазе NGX_HTTP_REWRITE_PHASE исполнится раньше чем дойдёт ход до NGX_HTTP_PREACCESS_PHASE.limit_req здесь не будет исполняться НИКОГДА
чтобы это решить нужно return вынести в именованный локейшин
Ч.Т.Д.Модели "обучились" на типичных ошибках/непонимании работы nginx и уверенно их воспроизводят, хотя cloude даже "нашёл" верный путь (порядок фаз), но "не смог" по нему пройти :)Если, что правильный ответ
$ GET -S example.comGET http://example.com200 OKroot: one two three auth_pre
происходит это, потому что сначала выполнятся ВСЕ set, потом апосле них выполнится директива auth_request и только потом в фазе NGX_HTTP_CONTENT_PHASE будет отдан контент
server { listen *:80; server_name .example.com; add_header "Content-Type" "text/html; charset=UTF-8" always; location /bu { return 200 'bu!\n'; }}
ну и если тот десятистрочник окажется для него неподъёмным дайте совсем детскую задачку
server { listen *:80; server_name .example.com; location / { rewrite ^ /one; return 200 "zero\n"; } location /one { return 200 "one\n"; }}
$ GET -S example.com
