- 1
- 2
- 3
- 4
- 5
- 6
- 7
if(isset($_SERVER['HTTP_X_REQUESTED_WITH']) && !empty($_SERVER['HTTP_X_REQUESTED_WITH']) && strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest') {
// Если к нам идёт Ajax запрос, то ловим его
echo 'Это ajax запрос!';
exit;
}
//Если это не ajax запрос
echo 'Это не ajax запрос!';
- Нет, это ajax запрос!
-Ага, потом отжимаем у него мобилу, деньги и отпиздюливаем ногами.
про аякс я не смотрел((
Просто так ни с того не с сего.
Открываю, листаю, читаю, понимаю -
Вот оно...
Его ещё и рекламировали?! Holufuckingshit.jpg
Сокращается до !empty($_SERVER['HTTP_X_REQUESTED_WITH'])
А остальное надо снифиром смотреть. Не уверен что так.
Да и какая разница Аякс или там хуякс. Запрос есть запрос пришел запрос отдай ответ. Если чего секурное хочешь вернуть проверяй права.
khujax
Пример: ссылка с onclick. При переходе перебрасывает на страницу с какой-то информацией, а по клику делается аякс запрос к этому же скрипту и информация подгружается в текущую страницу.
Тогда PHP-скрипт должен отдавать полный HTML для простого запроса и JSON/чуть обернутые в HTML данные для аякса. Если сделать два скрипта, они будут по сути дублировать друг друга. Если сделать дополнительный параметр, задающий выходной формат... ну можно, конечно, но смысл? Браузеры, умеющие HttpRequest, всё равно посылают заголовок.
Хм, про этот заголовок я как-то забыл, спасибо что напомнили.
Это какой-то тонкий троллинг или для вас правда нет разницы?
Заголовок - HTTP_X_REQUESTED_WITH
отсылают большинство java script фрейморков которые и позволяет нам без особых усилий понять что пришел ajax запрос
2. а остальны 20% как вы работате с ними?
еще интересней...
А почему вам не интересно? Ну например, у вас есть обработчик ajax запросов, а вы вдруг решили проверить HTTP_X_REQUESTED_WITH и вдруг обнаружили, что заголовок такой не передается 99% ваших пользователей, а еще и куки не передаются и User-Agent пустой. Какова ваша реакция - фиг с ним, - зато я обрабатываю запросы правильно?
Формат ответа стоит проверять всегда.
Если запрос ajax, отдать XML/JSON/HTML и т.д.
Если не ajax, отдать HTML страницу.
> Формат ответа стоит проверять всегда
Каким образм?
> Если не ajax, отдать HTML страницу.
Странный подход. Не знаю, как там в PHP, но в Java принято исходить из следующих факторов при выборе формата возвращаемого контента:
1. Значение Accept.
2. Расширение запрашиваемого документа.
3. Использовать тип ресурса по-умолчанию (html, к примеру).
Да и по большому счету то, что вы написали не конфликтует с моими словами. В чем странность моего подхода тогда?
Принимать во внимание Accept и расширение запрошенного документа стоит только в том случае, если вы самостоятельно отдаете все документы вашей информационной системы. В php эта практика далеко не всеми примелема. В частности я, например, не буду картинки отдавать через PHP, - я лучше подниму сервер под статику. Тем не менее, иногда удобно управлять любым контентом ИС централизовано - с этим я тоже согласен.
Полемика вокруг того, что я говорю, - нельзя не знать и не понимать то, как был запрошен документ (вы например смотрите на Accept), а Vasiliy говорит, что он не заморчивается по поводу любых HTTP-заголовков и считает, что важно только то, как данные обрабатываются - абсолютно неприемлемое мной мнение.
Кто-то просто обращается к одной и той-же странице передавая доп. заголовок.
К примеру
my_site.com/get_news.php
my_site.com/get_news.php
отличий нет но если обратиться с этой странице посредством доп. заголовка то данные будут возвращенные в другом формате.
Методов уйма но это не говорит о том что метод проверки на доп. заголовок говно код. Кому как нравиться так и делайте
my_site.com/get_news.html
my_site.com/get_news.json
и получать разный тип контента. Более того, со Spring даже лишний код писать не придётся.
Что не актуально не понял - ассинхронные запросы или заголовок этот много страдальный?
к нам едет ревизор!
(OMG)
у меня по данному вопросу немного двоякая позиция:
1. нужно тщательно проектировать API, и делать, чтобы по одному урлу отдавался контент строго определенного формата.
my_site.com/get_news.html - отдает хтмл и хуяксом, и так
my_site.com/get_news.json - отдает жсон и так и так.
2. в случае хтмл детект заголовков может быть нужен, чтобы решить, отдавать ли необходимый кусок или полностью, лэйаут, так сказать - для graceful degradation. Как, например, на говнокодике "Комментарии"
JSON должен стучаться куда-нибудь вообще в свою дверь, допустим /json.php?act=news&id=15, а сама новость доступна как /news/15
Кто вообще придумал, что один и тот же файл должен обслуживать все на свете? Неправильно поняли суть контроллера в MVC что ли?
И еще
>в случае хтмл детект заголовков может быть нужен, чтобы решить, отдавать ли необходимый кусок или полностью, лэйаут, так сказать - для graceful degradation. Как, например, на говнокодике "Комментарии"
Можно просто передать очевидный параметр ?no_head и все. Нужно всегда делать очевидные решения.
Допустим какой-то новичок хочет сделать агрегатор комментариев говнокода, ну захотелось ему.
Вот он смотрит и ох*евает - как с одного урла приходят разные по структуре вещи. А с параметром все просто и понятно.
> Неправильно поняли суть контроллера в MVC
You can not into REST.
Я просто про то, что для разного контента пути должны быть обязательно различными.
Абсолютно верно. У меня все запросы на выдачу пользователю html-контента всегда идут через единый контроллер.
Но при этом не стоит фанатеть, пихая все через контроллер. Например, доступ к API логичнее реализовать через другой контроллер, при этом не стоит делать глобальный контроллер для этих двух - в этом просто нет смысла.
Слепое следование MVC - далеко не всегда хорошо.
<?
echo "$_SERVER[HTTP_X_REQUESTED_WITH]<br />";
?>
результат
Notice: Undefined index: HTTP_X_REQUESTED_WITH in Z:\home\mycms.rul\www\style\script\php\r eg_form.php on line 23
вывод: HTTP_X_REQUESTED_WITH в топку )))
<?
dfskljgsd;lhjs;ohyiujt;slgk\lkfhjd;flhjf d;lhjrtoihjdl;tkhjdf;lghkjhg;hjgdf;hglkd ;
?>
Результат:
Notice: Use of undefined constant dfskljgsd - assumed 'dfskljgsd' in C:\__\b.php on line 2
Notice: Use of undefined constant lhjs - assumed 'lhjs' in C:\__\b.php on line 2
Notice: Use of undefined constant ohyiujt - assumed 'ohyiujt' in C:\__\b.php on line 2
Fatal error: Undefined constant 'slgk\lkfhjd' in C:\__\b.php on line 2
Вывод: пхп в топку.
Голландский?
<a href=http://mikrosaym.blogspot.ru><img>http://s015.radikal.ru/i332/1703/5e/143d0d0673f2.png</img></a>
НЕ ВЫХОДЯ ИЗ ДОМА Деньги на банковскую карту
КАК ЭТО РАБОТАЕТ?
ОФОРМЛЯЕТЕ ЗАЯВКУ
ПОЛУЧАЕТЕ ПОДТВЕРЖДЕНИЕ
ПОЛУЧАЕТЕ ДЕНЬГИ
<a href=http://mikrosaym.blogspot.ru><img>http://s020.radikal.ru/i711/1703/0d/40730bbd75ed.png</img></a>
<a href=http://bit.ly/2oI4psW>ВЫДАВАЙ МИКРОЗАЙМЫ С ГАРАНТИРОВАННОЙ ДОХОДНОСТЬЮ ОТ 192% ДО 265% ГОДОВЫХ И ЗАБУДЬ О ФИНАНСОВЫХ ПРОБЛЕМАХ</a>
-lu-
ЛЮБЫЕ ВТОРЫЕ ОЧКИ RAY-BAN В ПОДАРОК!
МОДЕЛИ и цвета НА ВЫБОР! Выберите свои Aviator, Wayfarer или Clubmaster!
http://kshop2.biz/KKUYcW - http://s16.radikal.ru/i191/1703/50/899c19cb0fe0.png
<a href=http://kshop2.biz/KKUYcW>брендовые солнцезащитные очки 2014</a>
<a href=http://kshop2.biz/KKUYcW>солнцезащитные очки prada официальный</a>
http://kshop2.biz/KKUYcW - очки ромео популяр купить
http://kshop2.biz/KKUYcW - очки для компьютера купить днепр
<a href=http://kshop2.biz/KKUYcW>широкие солнцезащитные очки купить</a>
http://kshop2.biz/KKUYcW - http://s019.radikal.ru/i634/1703/80/511fb7c108bc.png
=RAY BAN=
ЛЮБЫЕ ВТОРЫЕ ОЧКИ RAY-BAN В ПОДАРОК!
МОДЕЛИ и цвета НА ВЫБОР! Выберите свои Aviator, Wayfarer или Clubmaster!
http://kshop2.biz/KKUYcW - http://s020.radikal.ru/i700/1703/63/e61a680fd4f0.png
<a href=http://kshop2.biz/KKUYcW>золотые оправы очков купить екатеринбург</a>
http://kshop2.biz/KKUYcW - очки виртуальной реальности для смартфона купить в москве
http://kshop2.biz/KKUYcW - солнечные очки шаблон для фотошопа
<a href=http://kshop2.biz/KKUYcW>каким лицам идут солнцезащитные очки</a>
http://kshop2.biz/KKUYcW - alpina очки солнцезащитные
http://kshop2.biz/KKUYcW - http://s019.radikal.ru/i634/1703/80/511fb7c108bc.png
=RAY BAN=