Не могу сообразить, как мгновенно остановить работу скрипта в случае ошибки. Т.е.
скажем в какой-нибудь ячейки таблицы срабатывает оператор
exit(file_get_contents('../404.html')); // со одновременной загрузкой 404.html
Инфа, появляется внутри этой ячейки (оставляя все, что было выведенно браузером до этого события), а как сделать, чтоб произошла очистка экрана и кроме 404.html больше ничего не было.
Спустя 5 минут, 41 секунда (10.04.2011 - 10:20) uWeb написал(а):
Для этого нужно переслать пользователя ну другую страницу.
Спустя 15 минут, 37 секунд (10.04.2011 - 10:36) kirik написал(а):
Можно складировать то что выводится в переменную/буфер, а в случае ошибки выводить собственно ошибку, а не буфер.
Спустя 41 минута, 1 секунда (10.04.2011 - 11:17) GET написал(а):
uWeb
Спасибо, но ... хотел без этого обойтись. Интуитивно чувствую, что это не безопасно.
kirik, а как бы потом если ошибок нет, то уже тогда буфер на экран выводить, как бы двойная работа, а нет ли механизма, как в бейсике типа CLEAR или CLR , чтоб разом очистить страницу? не уходя с нее?...блин уверен, что нет...ПХП ее всяко разно придется грузить заново...гм..наверное все же лучше оставлю все как есть ..
интересно, а как выполняется, эта конструкция header('Location:index.php');
exit;..
если в index.php есть типа include ('err.php'); то exit; не успеет выполнится...все эти выкрутасы из за того, что начитался про перехваты редиректа и, когда начнет загружатся index.php он с предыдущей страницы все перемнные притащит за собой, которые можно будет прочитать
Может я мнительный просто...
Спасибо, но ... хотел без этого обойтись. Интуитивно чувствую, что это не безопасно.
kirik, а как бы потом если ошибок нет, то уже тогда буфер на экран выводить, как бы двойная работа, а нет ли механизма, как в бейсике типа CLEAR или CLR , чтоб разом очистить страницу? не уходя с нее?...блин уверен, что нет...ПХП ее всяко разно придется грузить заново...гм..наверное все же лучше оставлю все как есть ..
интересно, а как выполняется, эта конструкция header('Location:index.php');
exit;..
если в index.php есть типа include ('err.php'); то exit; не успеет выполнится...все эти выкрутасы из за того, что начитался про перехваты редиректа и, когда начнет загружатся index.php он с предыдущей страницы все перемнные притащит за собой, которые можно будет прочитать
Может я мнительный просто...
Спустя 7 минут, 30 секунд (10.04.2011 - 11:24) alex12060 написал(а):
Цитата |
Спасибо, но ... хотел без этого обойтись. Интуитивно чувствую, что это не безопасно. |
Обоснуйте...
Спустя 1 минута, 50 секунд (10.04.2011 - 11:26) GET написал(а):
alex12060
Цитата |
...все эти выкрутасы из за того, что начитался про перехваты редиректа и, когда начнет загружатся index.php он с предыдущей страницы все перемнные притащит за собой, которые можно будет прочитать Может я мнительный просто... |
Спустя 4 минуты, 21 секунда (10.04.2011 - 11:30) alex12060 написал(а):
Это параноя, а не мнимость)
При возникновении исключительно ситуации, можно выполнить сразу двоякую задачу.
Допустим, отказалась работать БД, тогда:
- Записываем данные в файл-лог
- Отправляем пользователя на странцу с ошибкой ( Не указывая и не передавая никаких ошибок )
А если "404 страница не найдена", то что там перехватывать то? Я этого понять не могу...
Обычные редирект делаете на 404-ую, без передачи параметров и все...
При возникновении исключительно ситуации, можно выполнить сразу двоякую задачу.
Допустим, отказалась работать БД, тогда:
- Записываем данные в файл-лог
- Отправляем пользователя на странцу с ошибкой ( Не указывая и не передавая никаких ошибок )
А если "404 страница не найдена", то что там перехватывать то? Я этого понять не могу...
Обычные редирект делаете на 404-ую, без передачи параметров и все...
Спустя 13 минут, 57 секунд (10.04.2011 - 11:44) GET написал(а):
alex12060
Может я конечно не прав и не понимаю до конца механизма работы, но я исхожу из того, что в этом случае при выполнении 404 если каким то образом прекрутить (удастся перенаправить на свой html или инклюдить) скажем это:
Я не хочу спорить с вами, я знаю, что мне еще учиться и учиться...просто ссыкатно бывает :)
Может я конечно не прав и не понимаю до конца механизма работы, но я исхожу из того, что в этом случае при выполнении 404 если каким то образом прекрутить (удастся перенаправить на свой html или инклюдить) скажем это:
, то чел прочитает и узнает название моих переменных. Например. Хотя там и стоит защита от инклюда, но на hackzone.ru они злые хакеры постоянно выкладывают куски взломанных сайтов и обсуждают их.
foreach ( $_SESSION as $key => $val ){ $$key = $val; print "$$key = $val <br>\n";}
Я не хочу спорить с вами, я знаю, что мне еще учиться и учиться...просто ссыкатно бывает :)
Спустя 11 минут, 46 секунд (10.04.2011 - 11:56) neadekvat написал(а):
A.B.C., и все-таки используйте буфер - его не просто так придумали. Хорошая вещь, сразу забываешь про проблемы с заголовками и выводом ошибок. Весь вывод в вашей власти. А без буфера приходится придумывать извращенские логики скрипта, размещать код вверх тормашками и т.д.
И, да, при ошибке не забывайте отдавать соответствующий заголовок:
И, да, при ошибке не забывайте отдавать соответствующий заголовок:
header("HTTP/1.1 404 Not Found");
Спустя 1 час, 23 минуты, 24 секунды (10.04.2011 - 13:20) killer8080 написал(а):
A.B.C.
объясните на каком основании вы собираетесь выкидывать 404 ошибку из-за внутренних ошибок сервера?
Так делать не в коем случае нельзя!
Представьте ситуацию, у вас по какой то причине упал серевр БД. И что увидит посетитель?
На всех страницах сайта 404 ошибка. Врядли он снова вернётся на ваш сайт. А если вы ещё и прислушаетесь к совету neadekvat-а
объясните на каком основании вы собираетесь выкидывать 404 ошибку из-за внутренних ошибок сервера?
Так делать не в коем случае нельзя!
Представьте ситуацию, у вас по какой то причине упал серевр БД. И что увидит посетитель?
На всех страницах сайта 404 ошибка. Врядли он снова вернётся на ваш сайт. А если вы ещё и прислушаетесь к совету neadekvat-а
Цитата (neadekvat @ 10.04.2011 - 10:56) |
И, да, при ошибке не забывайте отдавать соответствующий заголовок: header("HTTP/1.1 404 Not Found"); |
то ситуация усугубится многократно!
Если в это время ваш сайт индексировался поисковыми ботами, то поймав 404 статус эти страницы будут удалены из поискового индекса надолго (соответственно с потерей ТИЦ или pagerank и т.п.). Оно вам надо?
Единственно верное решение - использовать буферизацию и корректную обработку ошибок.
Спустя 3 минуты, 30 секунд (10.04.2011 - 13:23) neadekvat написал(а):
killer8080, я же не зря сказал о соответствующих ошибках.
В случаи, если недоступна база, логично отдать 503 ошибку. Но заголовок отправлять надо. Это стандарт. И поисковикам, кстати, тоже лучше знать, что вы именно временно недоступны, а то ненароком подумают, что "У нас упала бд, скоро исправим" - действительно ваш основной контент.
В случаи, если недоступна база, логично отдать 503 ошибку. Но заголовок отправлять надо. Это стандарт. И поисковикам, кстати, тоже лучше знать, что вы именно временно недоступны, а то ненароком подумают, что "У нас упала бд, скоро исправим" - действительно ваш основной контент.
Спустя 16 минут, 59 секунд (10.04.2011 - 13:40) killer8080 написал(а):
neadekvat
ну так с этого и надо было начинать. Если A.B.C. решил выкидывать 404 ошибку, вряд ли он станет формировать 503 статус, тем более что вы прямым текстом указали
ну так с этого и надо было начинать. Если A.B.C. решил выкидывать 404 ошибку, вряд ли он станет формировать 503 статус, тем более что вы прямым текстом указали
Цитата (neadekvat @ 10.04.2011 - 10:56) |
header("HTTP/1.1 404 Not Found"); |
Спустя 55 секунд (10.04.2011 - 13:41) neadekvat написал(а):
killer8080, то есть логичнее было к его 404 ошибке указать заголовок к 503?
Спустя 2 минуты (10.04.2011 - 13:43) killer8080 написал(а):
Логично указать человеку на суть ошибки, а не на её следствия
Спустя 1 минута, 21 секунда (10.04.2011 - 13:44) neadekvat написал(а):
killer8080, откуда мне знать, в каком случаи у автора эта ошибка возникает? Из контекста это совершенно неясно.
Спустя 7 минут, 16 секунд (10.04.2011 - 13:52) killer8080 написал(а):
Цитата (A.B.C. @ 10.04.2011 - 09:14) |
Не могу сообразить, как мгновенно остановить работу скрипта в случае ошибки. |
Цитата (A.B.C. @ 10.04.2011 - 10:44) |
Например. Хотя там и стоит защита от инклюда, но на hackzone.ru они злые хакерыпостоянно выкладывают куски взломанных сайтов и обсуждают их. |
В каком бы случае ни возникли внутренние ошибки это не повод выдавать 404!
Не вижу тут повода для спора, я просто указал ТС что так делать нильзя.
Спустя 5 минут, 40 секунд (10.04.2011 - 13:57) neadekvat написал(а):
Цитата (killer8080 @ 10.04.2011 - 14:52) |
Не вижу тут повода для спора, я просто указал ТС что так делать нильзя. |
Нет, вы привели цитату моих слов и сказали, что если следовать им, то будет совсем капец. Я должен был проглотить это? Не в этой жизни.
Спустя 13 минут, 23 секунды (10.04.2011 - 14:11) killer8080 написал(а):
Цитата (neadekvat @ 10.04.2011 - 12:57) |
Нет, вы привели цитату моих слов и сказали, что если следовать им, то будет совсем капец. |
Если в контексте того что пытается сделать ТС сделать то, что вы посоветовали прямым текстом, то да, именно так и будет. И свои слова я обосновал.
Цитата (neadekvat @ 10.04.2011 - 12:23) |
В случаи, если недоступна база, логично отдать 503 ошибку. Но заголовок отправлять надо. Это стандарт. И поисковикам, кстати, тоже лучше знать, что вы именно временно недоступны, а то ненароком подумают, что "У нас упала бд, скоро исправим" - действительно ваш основной контент. |
А вот это дельный совет, с него и надо было начинать
Спустя 9 минут, 57 секунд (10.04.2011 - 14:21) neadekvat написал(а):
Цитата (killer8080 @ 10.04.2011 - 15:11) |
А вот это дельный совет, с него и надо было начинать |
Начинать что? Я лишь указал автору, что помимо обычного сообщения надо отправлять также правильный заголовок - об этом говорится во всех документах от RFC до рекомендаций от поисковиков.
К тому же, я сразу дал понять, то отдавать надо соответствующий ситуации заголовок, и лишь привел пример.
Порой поднадоедает пересказывать учебники. Серьезно.
Спустя 1 час, 7 минут, 19 секунд (10.04.2011 - 15:28) GET написал(а):
Парни, не ругайтесь эта проблема не стоит этого, искренне большое спасибо, за советы...
Вообще я планировал ошибку 404 выдать, чтоб запутать:
к примеру в середине работы скрипта проверить отсутствует ли $_SESSION['user']?, чему навен? - выдаем ошибку 404. Если кто-то что-то подбирает, то чтоб не сразу разобрался из-за чего.
neadekvat, как раз читаю по поводу буфера.
Спасибо.
Вообще я планировал ошибку 404 выдать, чтоб запутать:
к примеру в середине работы скрипта проверить отсутствует ли $_SESSION['user']?, чему навен? - выдаем ошибку 404. Если кто-то что-то подбирает, то чтоб не сразу разобрался из-за чего.
neadekvat, как раз читаю по поводу буфера.
Спасибо.
Спустя 4 минуты, 4 секунды (10.04.2011 - 15:32) neadekvat написал(а):
Цитата (A.B.C. @ 10.04.2011 - 16:28) |
Парни, не ругайтесь эта проблема не стоит этого, искренне большое спасибо, за советы... |
Правильные заголовки - это действительно важная тема. Просто killer8080 надо было дополнить мой пост замечанием, а не опровергать его.
Цитата (A.B.C. @ 10.04.2011 - 16:28) |
к примеру в середине работы скрипта проверить отсутствует ли $_SESSION['user'] |
Сильно лучше не мудрите.
Ведь при взломе скрипт сначала прогонят в целом, по правилам вашей игры. И если после успешной авторизации человека перекидывает на member.php, а взломщиков, обращающихся к этому адресу, будет встречать 404-ая ошибка, они не поведутся на это, поверьте.
Спустя 6 минут, 35 секунд (10.04.2011 - 15:39) GET написал(а):
neadekvat
Спасибо, еще раз, а не посоветуете где почитать про буферизацию, на ИРБИСЕ что-то не могу найти...
Спасибо, еще раз, а не посоветуете где почитать про буферизацию, на ИРБИСЕ что-то не могу найти...
Спустя 3 минуты, 25 секунд (10.04.2011 - 15:42) neadekvat написал(а):
Да что там читать в принципе :)
Единственно - возможно, не сразу понятно, как себя ведут переменные в пределах буферизации и за их пределами. Ответ прост - так же, как и без буферизации.
Т.е. единственное отличие, что все, что отправляется в поток (выводится на экран), сначала собирается в памяти, а уже потом вы можете с этим делать, что хотите.
ob_start();
echo 'asdasd';
$content = ob_get_contents();
ob_end_clean();
echo 'My content: '. $content;
Единственно - возможно, не сразу понятно, как себя ведут переменные в пределах буферизации и за их пределами. Ответ прост - так же, как и без буферизации.
Т.е. единственное отличие, что все, что отправляется в поток (выводится на экран), сначала собирается в памяти, а уже потом вы можете с этим делать, что хотите.
Спустя 5 минут, 11 секунд (10.04.2011 - 15:47) GET написал(а):
))
neadekvat, а вот по опыту насколько это тормозит скрипт...я имею ввиду посреднечество ob_start();ob_end_clean();
все же наверное медленнее чем прямой вывод в браузер?
neadekvat, а вот по опыту насколько это тормозит скрипт...я имею ввиду посреднечество ob_start();ob_end_clean();
все же наверное медленнее чем прямой вывод в браузер?
Спустя 3 минуты, 38 секунд (10.04.2011 - 15:51) neadekvat написал(а):
Да, возможно, несколько медленнее. Но вы этого не заметите
Например, в одном разделе выводятся тексты весом в несколько кб. Скорость от 0,0х до 0,3 примерно. Так что переживать не о чем.
Например, в одном разделе выводятся тексты весом в несколько кб. Скорость от 0,0х до 0,3 примерно. Так что переживать не о чем.
Спустя 1 минута, 48 секунд (10.04.2011 - 15:53) GET написал(а):
neadekvat
Большое вам спасибо!
Большое вам спасибо!
Спустя 13 минут, 14 секунд (10.04.2011 - 16:06) killer8080 написал(а):
Цитата (A.B.C. @ 10.04.2011 - 14:47) |
насколько это тормозит скрипт...я имею ввиду посреднечество ob_start();ob_end_clean(); все же наверное медленнее чем прямой вывод в браузер? |
если вы используете механизм стандартных сессий, то буферизация уже задействована и запуск ob_start() на быстродействие не повлияет.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.