Php, изменение значений $_SERVER или все-таки лучше mod_rewrite и аналоги?
Насколько безопасно изменять массив $_SERVER в скрипте? А точнее REQUEST_URI, QUERY_STRING и им подобные.
Не могут ли разработчики php в дальнейшем сделать $_SERVER readonly, может кто изучал данный вопрос и есть информация. В офф доке я такой информации не увидел.
Надо сделать несколько рерайтов без редиректов, прозрачно для пользователя, точка входа в приложение одна, сервер apache. Изменяться адреса должны примерно по такому шаблону:
^item\.php\?id=(\d+) /base/item/$1
Но есть пара моментов:
1. Возможен уход от апача и соответственно переписывание рерайтов на nginx, lighttpd, etc
2. Я не очень силен в mod_rewrite, не все вещи могу делать, а при такой задаче насколько я поминаю еще возня дополнительная с кондишинами и флагами, с наскоку и часовому гуглению, сделать не вышло.
Просто через полчаса после переноса проекта на на новый движок, заказчик вспомнил о том что старые адреса надо сохранить. В используемом Yii штатными средствами роутинга такое не вышло. В срочном порядке сделал рерайт в php. Сейчас думаю как лучше переделать. Рад буду ответам и по php и по mod_rewrite.
Блин, хабр все поломал, когда ответ на коммент DevMan назначил решением, хотя можент только у меня… На всякий случай, все что я пишу про читай выше или ниже или второй коммент относится туда.
Ядро фреймворка (yii) работает с $_SERVER, точнее как я мельком посмотрел CHttpRequest, решение для себя нашел, сделать через расширение классов фреймворка. CHttpRequest или CUrlManager или CUrlRule расширять, это в понедельник виднее будет. Сейчас уже выходной)
массив $_SERVER такой же массив в глобальной видимости как и, допустим, только что созданный массив $qwe = array(1,2,3) Его изменения ни на что не повлияют, кроме логики программы которую Вы же делаете.
Другое дело что если Вам нужно изменить этот массив, то Ваша логика не правильна. Сделайте оболочку над массивом и ей оперируйте.
С изменения встроенных массивов нужно быть аккуратным. Легко получить трудно локализуемые баги из-за того, что некоторые функции (в частности фильтрации) работают не собственно с массивами $_SERVER, $_POST и т. п., а с внутренним представлением запроса, из которого массивы генерируются только при старте скрипта.
В nginx такой конфиг пишется элементарно. И лучше, имхо, делать такой рерайт через HTTP редирект 301 Moved Permanently, а не внутренними роутингом — и поисковики не будут видеть дублирование контента и клеить его на свое усмотрение, и пользователи пришедшие по старым внешним ссылкам (в т. ч. с поисковиков) занесут в букмарки уже новый ЧПУ.
Вот! Из-за правки глобальных массивов и спрашивал, не нравится так, сам столкнулся, когда неизвестный программист в середине проекта (система управлениями файлами и документами, перед помещением в Реестр (Regisrty)!!! изменял QUERY_STRING, видимо из-за того что туда тогда request ложили, чтобы с пармишанами так как они сделаны проблем не было) нашлось довольно легко, но было оч неприятно. Решение описанной в вопросе проблемы нашел для себя и выше ответил, спасибо за ответ.
И кстати, насчет редиректов 301. Сколько сам с этим сталкивался, Гугль прекрасно с работает, а вот я Яша несмотря на то что это описано в его тех. документации, не очень, иногда сайты сильно падают.
В Zend Framework, да и во многих других фреймворках, есть такое понятие, как объект запроса. Его вы можете менять, сколько душе угодно, и я думаю это правильный подход. На PHP уже не кодят глобальными переменными. Есть паттерны типа того же объекта запроса, регистра.
1. Не стоит ломать то, то работает
2. mod_rewite не напрягает
3. «переписывание» регулярки рерайтов для nginx не напрягает. Можно очень комфортно работать c nginx вообще без apache. К примеру, с PHP-CGI.
1. Я боюсь именно того, что это в далеком будущем работать не будет. Поэтому и спросил.
2. Не все еще понятно, может это мой косяк, что его мало изучал, может и скорее всего просто не было надобности, глубоко его учить, так лично все меньше с ним сталкиваюсь :)
3. Не напрягает, напрягает изучение специфичности сервера, технологии, etc если реальной надобности в этот момент нет. А так в nginx+php+fastcgi можно загодя влюбился посмотрев отсутствие 15-70мб кучи процессов apache у знакомого в top и соотвественно более стабильную работу, самому к сожалению еще не пришлось использовать.
1. Вообще не гламурно, лучше так не делать
2. Изучите, 5 минут займет, не более
3. Изучите, особо не напряжет. Потом еще и моральное удовлетворение получите
Средний
