Обычно на дне прикладного стека (каждого прикладного потока) присутствует т.н. "стоп-фрэйм". Нужно сильно постараться, чтобы его "перепрыгнуть". У стеков ядра строение может быть таким же или еще сложнее.
Секция кода (после релокации) обычно защищена от записи на уровне страниц.
Кстати, в IA-32 даже для линейного (виртуального) адресного пространства была возможность защищать пространство вне стека на уровне сегментации: code/data(bss)-сегменты "растут" снизу или покрывают все прикладное пространство, а стековый "растет" сверху прикладного пространства (user space). Подобный стековый сегмент мог быть у каждого прикладного потока или охватывать все стековое пространство процесса. У ядра, в разработке которого я участвовал, была такая опция.
Как выше написали, вам не помешает научиться лучше объяснять. Возможно, после этого вас будут лучше понимать. А просто опускать собеседника вместо объяснения любой д. может.
Приложение может вызвать что-нибудь уровня ядра, что может подвесить систему.
Также иногда в механизмах аппаратно-программной защиты находят ошибки, которые позволяют прикладному коду переключиться в режим ядра.
Вроде бы оставят для тех, у кого выходит не больше 20 млн/год.
В.В. выразил надежду, что 22% НДС - это временно. Правда, я не понял, потом будет еще больше или все-таки обратно откатят 😊
Я об этом и писал. Если у вас в шаблоне маршрута не описана строка запроса (хотя маршрутизатор позволяет), то соответственно запросы по адресам с вопросительным знаком на конце будут приводить к вызову обработчика ошибки, который выдает 404 и т.п. Например, посмотрите сайт у меня в подписи. Там используется каркас, не порождающий дубли. На уровень Web-сервера вынесена только обработка трэйлинг-слэшей. Все остальное внутри каркаса, в частности завершающий вопросительный знак будет "отброшен" при помощи общего шаблона адреса. Его окончание:
(\\?p=[1-9]\\d{0,9})?$#
Т.е. либо строка запроса по формату, либо никакой, включая разделитель вопросительный знак.
Да, адреса с вопросительным знаком на конце используются редко для какой-то другой функциональности, чем 404/301.
Если у вас шаблоны адресов в маршрутах описывают в том числе и строку запроса (query string) или ее отсутствие, то специально что-то общее можно не писать. Общая проверка на ранних этапах обработки запроса может быть даже хуже, чем частные или более комплексные общие на поздних. Даже несмотря на то, что в последнем случае нужно еще передавать управление php, etc.
Непосредственно в Axelname столько же при наличии 10 доменов.
Но ты же понимаешь, что почти все пользователи этого форума не держат репозитории своих сайтов даже на локалке. Самый распространенный способ развертывания кода - "закинуть" архив дистрибутива на сервер и там распаковать, установить/настроить, либо скопировать распакованный дистрибутив. То же самое касается "контента", когда идет речь о технологических операциях: копируют архивы с дампами баз данных и каталогами файлов данных. С отдельными элементами кода и данных могут поступать аналогично. Хотя контент обычно загружают через админку. И даже программные модули могут скачать/установить через админку.
Кстати, если на то пошло, можно и отдельные файлы данных загружать при помощи VCS. С клиентским кэшированием одноименных файлов бороться точно так же, как и с кэшированием JS/CSS-кода. Хотя с индексированием будет сложно. Тоже понадобятся комплексные операции.
