Ошибками в протоколе HTTP называется такое поведение веб-сервера, когда он по какой-то причине не может успешно отправить клиенту запрашиваемый документ. Сервер сообщает клиенту в HTTP-заголовке код ошибки, который на стороне клиента так или иначе интерпретируется браузером.
Каждая ошибка, выдаваемая веб-сервером, имеет код соответствующий классу возникшей ошибки. Коды ошибок (например 403 или 404) стандартизованы и подробно описаны в интернет-стандарте RFC2616 (Hypertext Transfer Protocol -- HTTP/1.1). Вы можете обращаться к этому документу за подробным описанием конкретной ошибки как в первоисточнику.
Коды ошибок бывают положительными и отрицательными или успешными и неуспешными. Есть четыре типа кодов:
2xx - запрос выполнен успешно - сервер успешно отправил клиенту запрашиваемый документ
3xx - запрос успешно перенаправлен - тоже положительный код. Он говорит о том, что запрос клиента был перенаправлен. Используется при работе с кэширующими серверами, а также в алгоритме, когда браузер клиента проверяет актуальность документа на сервере (дату создания, размер и так далее)
4xx - ошибка - документ не был отправлен клиенту, так как произошла критическая ошибка. Например, запрошенный документ не найден на сервере, доступ к документу запрещен и так далее
5xx - ошибка сервера - критическая ошибка на сервере. Например, на сервере не смог нормально отработать скрипт пользователя
Возможные ошибки при первичном размещении сайта
Вы разместили сайт на хостинге компании yutex, загрузили файлы и получили ошибку 403 при попытке открыть сайт через браузер. Эта ошибка возникает в случае если вы назвали индексный файл, который должен показываться при обращении к каталогу, неправильно. Индексный файл может иметь названия index.html, index.htm, index.php, index.phtml, index.shtml, default.htm или default.html. В Unix-системах регистр букв в названиях файлов имеет значение (!).
Ошибка - показывается список файлов вместо первой страницы
Возможно задано неверное имя главного/индексного файла. Индексный файл может иметь названия index.html, index.htm, index.php, index.phtml, index.shtml, default.htm или default.html
ошибка 403 "Доступ запрещен" - как устранить причины
Данная ошибка возникает когда сервер не смог обработать запрос по причине того, что доступ к файлу был запрещен. Наиболее часто это возникает в трех случаях:
в каталоге нет индексного файла (index.html, например) и при этом запрещен просмотр списка файлов в данном каталоге* или на всем виртуальном сервере. Можно попробовать создать файл с именем index.html и посмотреть не исчезнет ли ошибка.
выставлены такие "права" доступа на файл, что веб-сервер Apache не смог прочитать файл на диске сервера. Попробуйте изменить права доступа на 640, например.
пользователь попытался обратиться к скрипту (в каталоге cgi-bin), на который выставлены неправильные права - нет права на чтение+исполнение (r+x) конкретного скрипта. Измените права на 755.
*) По умолчанию просмотр списка файлов в каталоге запрещен. Для того, чтобы разрешить вывод списка файлов необходимо создать файл .htaccess, в котором прописать директиву Options +Indexes в виде отдельной строки.
обработка ошибки 404 "Файл не найден"
Ошибка 404 (Файл не найден) возникает когда пользователь запрашивает у веб-сервера документ, которого нет на диске. То есть, когда пользователь запрашивает несуществующий файл. Это наиболее "популярная" из всех ошибок. Вы можете наблюдать возникновение таких ошибок в файле error_log и учитывать это - отслеживать какие документы на сервере "не найдены" и корректировать неправильные ссылки из своих html-документов. Также ссылки на несуществующие документы могут вести с других сайтов.
Для удобства посетителей сайта можно обрабатывать ошибки 404 заменяя стандартные ответы веб-сервера на свои страницы с "человеческим" описанием причины возникновения ошибки и советами что делать в этом случае. Также полезно разместить на такой странице карту вашего сайта или ссылку на поисковую систему.
Как обрабатывать ошибку 404. Создайте в каталоге public_html файл .htaccess и поместите в него следующую инструкцию для веб-сервера Apache:
ErrorDocument 404 /404.html
Затем создайте файл 404.html, в который поместите описание возникшей ошибки и советы о том что "что делать" в этом случае посетителю вашего сайта. Теперь пользователь, который наберет в своем браузере адрес несуществующей страницы, будет автоматически перенаправлен сервером на файл 404.html.
С помощью директивы ErrorDocument можно обрабатывать не только ошибку 404, но и практически все другие ошибки. Например, можно обработать так и ошибку 403, которая упоминается в этом документе выше. О файле .htaccess и его практическом использовании можно почитать тут.
ошибка 500 "Internal Server Error"
Ошибка 500 "Internal Server Error" возникает в случае невозможности запуска скрипта, который вы разместили на сервере, в случае ошибок в скрипте, а также в случае когда вы поместили неправильную инструкцию в файл .htaccess. Этот список причин возникновения ошибки 500 не конечный, есть еще масса причин, по которым может возникнуть ошибка 500. Однако, упомянутые три случая встречаются наиболее часто.
Рассмотрим сначала случай, когда вы поместили некорректную инструкцию в файл .htaccess. Если вы ошиблись в написании названия нужной директивы или параметров к ней, в файле error.log вы найдете примерно такую ошибку:
[Wed Apr 14 17:01:38 2004] [alert] [client 217.16.16.16] /home/uXXXXX/aaa.ru/www/.htaccess: Invalid command 'DrectoryIndex', perhaps mis-spelled or defined by a module not included in the server configuration
Веб-сервер укажет вам какую конкретно директиву он посчитал ошибочной - ее нужно будет исправить. В данном случае веб-сервер сообщил что директивы DrectoryIndex он не знает. И действительно - нет директивы DrectoryIndex, есть DirectoryIndex. Имеет место опечатка.
Если ошибка 500 возникает при обращении к скрипту на языке Perl, размещенному в каталоге cgi-bin, нужно проверить права доступа на этот скрипт. Права должны быть 755 (rwxrx-rx). Если это не так, нужно изменить права на 755 командой chmod 755 script.pl в unix shell или воспользоваться для этого FTP. Нужно отдельно отметить - права на скрипты должны быть установлены строго в 755.
Пожалуйста, проверьте правильный ли режим передачи файлов по FTP вы использовали при загрузке скрипта на наш сервер. Все скрипты, равно как и любые другие текстовые файлы, должны передаваться по FTP в текстовом (ASCII) режиме. Если же был использован двоичный (Binary) режим передачи файлов, скрипты наверняка работать не будут.
Если после проверки корректности установленных прав на файл скрипта ошибка не исчезла, нужно изучить последние записи в файле error.log - в него веб-сервер помещает все сообщения об ошибках. Так вы найдете строчку вида
[Fri Apr 9 15:05:31 2004] [error] [client 217.16.16.16] Premature end of script headers: /home/uXXXX/aaa.ru/cgi-bin/scrip t.pl
Первое, что нужно сделать если вы получили такую ошибку, это проверить правильно ли скрипт выдает HTTP-заголовки. Каждый скрипт должен сначала печатать строку с указанием соответствующего Content-type и только потом непосредственно то, что увидит пользователь (например, HTML-код). Пример строки для выдачи заголовка обычного HTML-документа:
Если и после выдачи правильных заголовков ошибка 500 не исчезла, нужно проверить корректность работы скрипта в целом. Для этого нужно получить доступ в unix shell и далее выполнить команду проверки синтаксиса:
> perl -cw script.pl script.pl syntax OK
Если скрипт написан с ошибками, нужно будет исправить ошибки, руководствуясь соответствующей диагностикой, а также проверить синтаксис скрипта снова.
Champion ошибка 403 "Доступ запрещен" - как устранить причины
Данная ошибка возникает когда сервер не смог обработать запрос по причине того, что доступ к файлу был запрещен. Наиболее часто это возникает в трех случаях:
в каталоге нет индексного файла (index.html, например) и при этом запрещен просмотр списка файлов в данном каталоге* или на всем виртуальном сервере. Можно попробовать создать файл с именем index.html и посмотреть не исчезнет ли ошибка.
выставлены такие "права" доступа на файл, что веб-сервер Apache не смог прочитать файл на диске сервера. Попробуйте изменить права доступа на 640, например.
пользователь попытался обратиться к скрипту (в каталоге cgi-bin), на который выставлены неправильные права - нет права на чтение+исполнение (r+x) конкретного скрипта. Измените права на 755.
*) По умолчанию просмотр списка файлов в каталоге запрещен. Для того, чтобы разрешить вывод списка файлов необходимо создать файл .htaccess, в котором прописать директиву Options +Indexes в виде отдельной строки.
В результате url преобразуется во второй вид, но в командной строке будет неизменяемый результат. А в php Вы сможите принять переменные в виде GET, т.е. если наберем в браузере sait.ru/news/2008/11/20 получим переменные
scuter
Программирование - это вечное мучение. Один и тот же пользователь, сегодня и уже завтра, видит по-разному идеал CMS. Поэтому набираем пару хороших клиентов и постоянно работаем с ними. Ну, естественно делая для одного более лучшее обновление на 70% пригодится и остальным.
Клиент может знать только Вашу никому не знакомую CMS , но не знать, например DLE. А переходить на новый движок и изучать его, мало кому хочется - лучше, когда один доводится до ума.
Естественно любителей полной халявы, нужно отправлять на .... книжку по программированию читать!
Теперь начнем с того, что не обязательно формировать XML документ.
Теперь премер который раставит все по своим местам:
Пользователю необходимо зарегистрироватся. Нам нужно проверить логин и email на наличие в БД. Т.е. нам нужно сделать 2 запроса. Реализовать можно так:
1) ввели логин, отправили в какой-то скрипт, тот выводит не XML документ, а просто 1 или 0. Т.е. 1 - все ок, 0 - уже есть такое в БД или какие-то еще причины.
2) Вернули в JavaScript через responseText и условный оператор, если 1 - то выводим галочку, если 0 - то красный крестик.
MasterofCDM
Получаешь ответ и делишь его по регулярным выражениям (Добавление) Agassi
Ничего конечно против, но лично для меня: лишнии формы они только как мусор на странице. А так все упрощено.
IOpeH
Данные сессии хранятся на сервере, я не проверял но думаю разработчики подсуетили, чтоб этого нельзя было подстроить, так ужж легко => смысла парится нет со всякими данными.
vitaliy_mad
1) Что Вас пугает в БД???
2) Без БД не никакого смысла, вообще парится с этой всей фигней. На сайте еще миллион дыр где можно будет просто лезть и брать все безнаказуемо.
Все это как пороль и логин: просто передавая пароль и логин - мы просто отдаем доступ, а мой описаный случай пологается только на везенеи делитанта в получениии доступа.
Чтоб проверить логин и пароль, Вам необходимо так же обращатся авторизацией. С помощью данного метода мы просто авторизацию проводим автоматически. А не обходим ее.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 1459
