Как сделать страницу 404?
Для каждого сайта рекомендуется создавать собственные страницы ошибок, которые не будут функционально и визуально отличаться от других страниц этого сайта.
В профессиональных шаблонах (темах) для популярных CMS уже предусмотрены свои страницы ошибок, но они почти всегда не соответствуют принципам юзабилити и рекомендациям поисковых систем. Чтобы привести их в соответствие хотя бы минимальным требованиям, достаточно иметь доступ к HTML-файлу для редактирования.
Также в зависимости от CMS существуют и другие способы сделать страницу ошибки, внешне и функционально соответствующую сайту:
Также если сайт функционирует на сервере Apache, то в корне сайта можно создать HTML-файл, который будет отображаться при запросах несуществующих страниц, а в файле .htaccess разместить следующий код:
404 Not Found
Код состояния HTTP — это часть строки заголовка, ответа веб сервера на запрос клиента, информирующая о результате запроса и о том, что клиент должен предпринять далее. Думаю не все знают как выглядит заголовок ответа сервера, зато уверен, каждый, пользующийся интернетом, не раз сталкивались, со страницей 404 Not Found или 403 Forbadden. Это и есть, видимый пользователю результат, выдачи сервером, того или иного кода статуса в строке заголовке.
Коды состояния HTTP, разделены на 5 категорий. Клиент может быть не знаком с тем или иным кодом ответа HTTP, однако он должен отреагировать согласно категории кода. Итак протокол HTTP поддерживает следующие коды статуса, разделенные по категориям:
Information — информационные
Коды данной категории, сообщают клиенту, что для завершения запроса, ему необходимо выполнить дополнительный запрос, как правило по другому URI, соответствующий адрес указывается в строке Location, ответа сервера. Программа — клиент может совершать дополнительные запросы без участия пользователя, при условии что дополнительный запрос делается методами GET или HEAD.
Некоторые клиенты некорректно работают с редиректами 301 и 302, применяя в запросе ко второму ресурсу метод GET, несмотря на то, что первый запрос был сделан с использованием другого метода. В протоколеHTTP версии 1.1, вместо ответа статуса 302, были введены дополнительные коды ответов, 303 и 307. Изменять метод, необходимо только в случает ответа сервера со статусом 303, в остальных случаях использовать исходный метод.
300 Multiple Choices — Несколько вариантов выбора. По запрошенному URI, существует несколько вариантов ресурса, различных по MIME типу. языку или другим признакам. В ответе сервера, передается список альтернатив, выбираемый клиентским приложением автоматически или самим пользователем. Появился в протоколе версии HTTP/1.0. 301 Moved Permanently — Перемещёно окончательно. Запрошенный ресурс был окончательно перемещен на URI, указанный в строке заголовка Location, ответа сервера. Некоторые клиенты, при обработке данного кода, ведут себя некорректно, см. выше. Появился в протоколе версии HTTP/1.0. 302 Found — Найдено ( Moved Temporarily ) Данный код статуса сообщает клиенту, что ресурс временно доступен по другому URI, указанному в строке заголовка Location, заголовка ответа сервера. Данный код используется например, при согласовании содержимого ( Content Negotiation ), выполняемого сервером. Появился в протоколе версии HTTP/1.0. 303 See Other — Смотреть другое. Документ из запрошенного URI, нужно запросить по адресу, указанному в строке заголовка Location, заголовка ответа сервера, используя метод GET, невзирая на то, каким методом был сделан первый запрос. Появился в протоколе версии HTTP/1.1. 304 Not Modified — Не изменялось. Данный код выдается в случае запроса документа, методом GET, с использованием заголовков If-Modified-Since или If-None-Match, и документ не был изменен с указанного момента времени. Появился в протоколе версии HTTP/1.0. 305 Use Proxy — Использовать прокси сервер. Запрос к ресурсу, должен выполняться через прокси-сервер., адрес которого, указан в строке заголовка Location, заголовка ответа сервера. Появился в протоколе версии HTTP/1.1. 307 Temporary Redirect — Временное перенаправление Запрошенный ресурс временно доступен по URI, указанному в строке заголовка Location, заголовка ответа сервера. Появился в протоколе версии HTTP/1.1.
Коды данной категории служат для указание на ошибку со стороны клиента. При использовании любых методов запроса, кроме HEAD, сервера возвращает пользователю гипертекстовое пояснение по данной ошибке.
Коды данной категории, предназначены для ситуаций, когда обработка запроса не возможна по вине сервера. Во всех случаях, кроме использования метода HEAD, сервер должен включать в тело ответа, объяснение для пользователя.
500 Internal Server Error — Внутренняя ошибка сервера. Любая внутренняя ошибка на стороне сервера не подпадающая под остальные ошибки из категории 5хх. Появился в протоколе версии HTTP/1.0. 501 Not Implemented — Не реализовано. Сервер не поддерживает, необходимых для обработки запроса, возможностей. ( например не поддерживается необходимый метод обработки ). Появился в протоколе версии HTTP/1.0. 502 Bad Gateway — Плохой шлюз. Сервер, работающий в качестве прокси или шлюза, получил сообщение о неудачное в промежуточной операции. Появился в протоколе версии HTTP/1.0. 503 Service Unavailable — Сервис недоступен. Сервер не в состоянии обрабатывать запросы клиентов по техническим причинам. Появился в протоколе версии HTTP/1.0. 504 Gateway Timeout — Истек таймаут ожидания ответа шлюза. Проксирующий сервер или шлюз, не дождался ответа от вышестоящего сервера для завершения обработки запроса. Появился в протоколе версии HTTP/1.0. 505 HTTP Version Not Supported — Версия HTTP протокола не поддерживается. Сервер не поддерживает, или не может обработать, указанную в заголовке версию HTTP протокола. Появился в протоколе версии HTTP/1.0. 506 Variant Also Negotiates — Вариант тоже согласован. Из-за не верной конфигурации, выбранный вариант указывает сам на себя, в следствии чего, связывание прерывается. Добавлено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation. 507 Insufficient Storage — Переполнение хранилища. Недостаточно места для обработки текущего запроса. Возможно временная проблема. Используется в протоколе WebDAV. 509 Bandwidth Limit Exceeded — Пропускная возможность канала исчерпана. Данный код статуса, используется в случае превышения веб площадкой, отведенного ей лимита, на потребляемый трафик. Данный код не описан ни одним RFC и используется только модулем bw/limited, панели веб-хостинга cPanel. 510 Not Extended — Нет расширения. У сервера отсутствует расширение, которое пытается использовать клиентом. Сервер может передавать информацию, об имеющихся у него расширениях. Введено в RFC 2774 для дополнения протокола HTTPподдержкой расширений.
Методы обработки запросов HTTP
HTTP метод — это основная операция, которую необходимо выполнить над ресурсом. В названии могут использоваться любые символы, кроме управляющих последовательностей и разделителей, как правило это короткое слово на английском языке. Имена методов HTTP зависимы от регистра.
Любой веб сервер обязан работать, по крайней мере с двумя методами GET и HEAD. Если сервер не смог определить метод, указанный в заголовке запроса клиента, он должен вернуть код статуса 501 (Not Implemented), если-же метод серверу известен, но неприменим к данному ресурсу, будет возвращен код статуса 405 (Method Not Allowed). Как в первом, так и во втором случае, сервер должен включить в свой ответ, заголовок Allow со списком методов, которые он поддерживает.
Метод OPTIONS
Данный метод используется для выяснения поддерживаемых веб-сервером возможностей или параметров соединения с конкретным ресурсом. Сервер включает в ответный запрос заголовок Allow, со списком поддерживаемых методов и возможно информацию о поддерживаемых расширениях. Тело запроса клиента, содержит информацию об интересующих его данных, но на данном этапе формат тела и порядок работы с ним, не определен, пока, сервер должен его игнорировать. С ответным запросом сервера, происходит аналогичная ситуация.
Что-бы выяснить возможности сервера, клиент должен указать в запросе URI, символ — «*«, то есть данный запрос к серверу выглядит как: OPTIONS * HTTP/1.1. Кроме прочего, данный запрос может быть использован для проверки работоспособности сервера и поддержки им протокола HTTP, версии 1.1. Результаты данного запроса не кэшируются.
Метод GET
Метод GET, применяется для запроса конкретного ресурса. Так-же с помощью GET, может быть инициирован некий процесс, при этом, в тело ответа, включается информация о ходе выполнения инициированного запросом действия.
Параметры для выполнения запроса, передаются в URI запрашиваемого ресурса, после символа «?«. Запрос в таком случае выглядит примерно так: GET /some/resource?param1=val1¶m2=val2 HTTP/1.1.
Как установлено в стандарте HTTP, запросы методом GET, являются идемпотентными, то есть, повторная отправка одного и того-же запроса, методом GET, должна приводить к одному и тому-же результату, в случае, если сам ресурс, в промежутках между запросами, изменен не был, что позволяет кэшировать результаты, выдаваемые на запрос методом GET.
Кроме вышесказанного, существуют еще два вида метода GET, это: условный GET, содержащий заголовки If-Modified-Since, If-Match, If-Range и им подобные, Частичный GET, содержащий заголовок Range с указанием байтового диапазона данных, которые сервер должен отдать. Данный вид запроса используется для докачки и организации многопоточных закачек.
Порядок работы с этими подвидами запроса GET, стандартами определен отдельно.
Метод HEAD
Данный метод, аналогичен методу GET, с той лишь разницей, что сервер не отправляет тело ответа. Метод HEAD, как правило используется для получения метаданных ресурса, проверки URL ( есть-ли указанный ресурс на самом деле ) и для выяснения факта изменения ресурса с момента последнего обращения к нему.
Заголовки ответа могут быть закэшированы, при несоответствии метаданных и информации в кэше, копия ресурса помечается как устаревшая.
Метод POST
Метод POST, используется для передачи пользовательских данных на сервер, указанному ресурсу. Примером может послужить HTML форма с указанным атрибутом Method=»POST», для отправки комментария к статье. После заполнения необходимых полей формы, пользователь жмет кнопку «Отправить» и данные, методом POST, передаются серверному сценарию, который в свою очередь выводит их на странице комментариев. Таким-же образом, с помощью метода POST, можно передавать файлы.
В отличии от GET, метод POST, не является идемпотентным, то есть неоднократное повторение запроса POST, может выдавать разные результаты. В нашем случае, будет появляться новая копия комментария при каждом запросе.
Если в результате запроса методом POST, возвращается код 200 (Ok) или 204 (No Content), в тело ответа сервера, добавляется сообщение о результате выполнения запроса. Например, если был создан ресурс, сервер вернет 201 (Created), указав при этом URI созданного ресурса в заголовке Location.
Ответы сервера, на выполнение метода POST, не кэшируются.
Метод PUT
Используется для загрузки данных запроса на указанный URI. В случае отсутствия ресурса по указанному в заголовке URI, сервер создает его и возвращает код статуса 201 (Created), если ресурс присутствовал и был изменен в результате запроса PUT, выдается код статуса 200 (Ok) или 204 (No Content). Если какой-то из переданных серверу заголовков Content-*, не опознан или не может быть использован в данной ситуации, сервер возвращает статус ошибки 501 (Not Implemented).
Главное различие методов PUT и POST в том, что при методе POST, предполагается, что по указанному URI, будет производиться обработка, передаваемых клиентом данных, а при методе PUT, клиент подразумевает, что загружаемые данные уже соответствуют ресурсу, расположенному по данному URI.
Ответы сервера при методе PUT не кэшируются.
Метод PATCH
Работает аналогично методу PUT, но применяется только к определенному фрагменту ресурса.
Метод DELETE
Удаляет ресурс, расположенный по заданному URI.
Метод TRACE
При запросе методом TRACE, клиент может увидеть, какие изменения были сделаны в запросе, промежуточными серверами.
Метод LINK
Связывает указанный ресурс с другим ресурсом.
Ошибки публикации базы и веб сервиса на веб сервере 1C+ Apache +Linux.
Многие из нас привыкли публиковать базу или веб сервис 1С нажатием нескольких кнопок.
Но не все из многих знают, что для этого необходимо запустить(от имени администратора!) конфигуратор 1С:Предприятие именно на той машине, где установлен веб сервер(а именно компонента веб-расширения 1С:Предприятия).
В случае, если веб-сервер и компонента веб-расширения 1С:Предприятия установлены на машину с ОС Linux без графической оболочки, то публикация через привычное окно конфигуратора становится невозможной.
Аналогичная ситуация возникает, когда на этой машине отсутствует клиент 1С:Предприятия и, следовательно, становится невозможным запуск конфигуратора.
О том, как осуществить публикацию базы можно почитать тут: Публикация 1С на Веб сервере Linux.
Отметим, что при ручной настройке публикации можно допустить различные ошибки. Описания которых и приведены в этой статье.
Итак, что делать, если не получается опубликовать веб-сервис 1С?
Список возможных ошибок:
Ошибка 500
При работе с некорректным HTTP сервисом из внешних программ возвращалась ошибка 500, которая ни о чем конкретном не говорит. «500 Internal Server Error — любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса».
Вроде HTTP сервис один, а при использовании запросов к нему из разных программ возвращались разные ошибки.
Пример создания HTTP-сервисов на платформе «1С
В этой статье разбираются демонстрационные HTTP-сервисы, созданные в демонстрационной конфигурации «Управляемое приложение» для платформы «1С:Предприятие» версии 8.3.5 и старше.
Цель статьи – помочь разобраться с использованием технологии HTTP-сервисов и показать практическое применение некоторых неочевидных механизмов.
Демонстрационная база «Управляемое приложение» представляет собой простую конфигурацию, в которой создано большинство объектов, которые могут понадобиться при автоматизации деятельности небольшой торговой фирмы. В частности, в ней присутствует справочник «Товары». Элементами этого справочника мы будем управлять при помощи HTTP-сервиса. Такой сценарий может возникнуть, например, при интеграции с интернет-магазином или другой корпоративной ИС, в которую заносится первичная информация о товарах.
Для удобства изучения описываемых HTTP-сервисов рекомендуется включить авторизацию ОС при публикации на веб-сервере и настроить пользователю с ролью «Администратор» использование windows-аутентификации от имени пользователя ОС, под которым будет проходить изучение.
Ошибка «Узел не прошел проверку» при обращении к веб-сервису
не могу понять, откуда он (сервер) берет настройку web-прокси.Если запустить IE от имени этого ползователи и ввести этот ***wsdl — все открывается.
туплю ине могу сдвинуться Если кто сталкивался или есть идеи — буду весьма признателен
А на сервере никаких переменных среды не выставлено на тему прокси?
(обязательный) Тип: Строка. Местоположение WSDL файла, откуда будет получено определение веб-сервисов. (необязательный) Тип: Строка. Имя пользователя, которое будет использоваться для аутентификации при получении определений веб-сервисов. (необязательный) Тип: Строка. Пароль пользователя, который будет использоваться для аутентификации при получении определений веб-сервисов. (необязательный) Тип: ИнтернетПрокси. Содержит объект ИнтернетПрокси, используемый для загрузки WSDL документа по протоколу HTTP.Если не указан, то используются настройки прокси по умолчанию.Значение по умолчанию: Неопределено. (необязательный) Тип: Число. Таймаут соединения, осуществляемого для загрузки WSDL описания веб-сервиса, в секундах. 0 — не устанавливать таймаут.Значение по умолчанию: 0. (необязательный) Тип: ЗащищенноеСоединениеOpenSSL; ЗащищенноеСоединениеNSS; Неопределено. Объект защищенного соединения для осуществления HTTPS соединения для загрузки WSDL описания веб-сервиса.Значение по умолчанию: Неопределено. Описание:
Создает определение веб-сервисов из WSDL файла.
Порт (Port) Сервер (Server) Установить (Set) Конструкторы:
Формирование неинициализированного объекта
Описывает параметры прокси-серверов для различных протоколов. Допустимые протоколы для использования в объекте ИнтернетПрокси задаются строками http, https и ftp.Позволяет использовать аутентификацию по имени пользователя и паролю или NTLM (Integrated Security) аутентификацию (в версии 1С:Предприятия под Windows). NTLM аутентификация используется по умолчанию для прокси-серверов, поддерживающих данный способ аутентификации, и не требует дополнительных настроек, т.е. NTLM аутентификация будет использоваться, если в конструкторе объекта HTTPСоединение прокси не задан или задан, но без указания имени пользователя и пароля. Задание в конструкторе объекта HTTPСоединение прокси с указанным именем пользователя и паролем отключает NTLM аутентификацию, для аутентификации в этом случае используется HTTP Basic аутентификация.
Тонкий клиент, сервер, толстый клиент, внешнее соединение, мобильное приложение(клиент), мобильное приложение(сервер). См. также: EuVod (2) ничо не выявлено (( IE открывает замечательно, в прокси нелезет
(3) у нас тут платформа 8.2.19тут написано:WSОпределения (WSDefinitions)Из WSDL файлаСинтаксис:
Всем спасибо, все хорошо теперь)
TurboConf 5 — расширение возможностей Конфигуратора 1С
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку «Обновить» в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно. Но вы можете создать новую ветку и вам обязательно ответят! Каждый час на Волшебном форуме бывает более 2000 человек.
Ошибка и страница 404 Not Found
Далеко не всегда сервер возвращает правильный ответ 404 Not Found (не найдено) на запросы несуществующих страниц, и еще реже страница ошибки 404 соответствует принципам юзабилити и дизайну сайта. Эти технические недостатки могут мешать поисковым роботам правильно индексировать сайт, а реальным пользователям — взаимодействовать с сайтом, что в совокупности негативно отражается на ранжировании.
Ошибка Service not found при обращении к веб-сервису 1С
Пример полного текста ошибки:
При обращении к веб-сервису, после авторизации(если таковая требуется) – возникает ошибка, что сервис не найден. То есть публикация самой базы отвечает, но веб-сервиса нет или он не отвечает.
Ошибка часто связана с ошибками в именах самого веб-сервиса или его ссылки.
Проверить имена веб-сервисов и ссылок на них.
point name – имя сервиса в конфигураторе;
alias – это имя ссылки, по которой будем обращаться к веб-сервису. Именно это имя необходимо вводить в браузер при проверке работы веб-сервиса.
В нашем случае веб-сервиса ws_1s_on_3.1cws нет в файле.
1) данную статью в формате ;
) две модифицированные демонстрационные базы
– «Поставщик» дополненную справочником Сотрудники и немного измененным web-сервисом «Сотрудники» от Трактор’а (за что ему огромная благодарность);
– «Получатель» дополненную обработкой получения списка сотрудников через ;
3) файлы comcntrcfg.xml и webservicecfg.xml
1) Подготовка к отладке сервиса
Цитата из ЖКК:
«Для указания внешнему соединению или web-сервису необходимости запуска в отладочном режиме используют настройки, размещенные в xml-файлах (comcntrcfg.xml и webservicecfg.xml соответственно), которые должны располагаться в подкаталоге CONF каталога исполняемого файла 1С:Предприятия 8.1 (BIN). Если файл не найден, приложение открывается в обычном режиме.»
Согласно вышенаписанному в подкаталог 1С:Предприятия 8.1 / помещаем два файла comcntrcfg.xml и webservicecfg.xml:
Листинг файла webservicecfg.xml:
2) Настройка отладки в конфигурации, содержащей -сервис (Поставщик)
Запускаем конфигуратор для Поставщик.
Публикуем -сервис «Сотрудники»:
Открываем модуль -сервиса Сотрудники и ставим в коде точку остановки.
Далее идем в меню Сервис-Параметры:
В диалоге Автоматическое подключение включаем флажок -сервисы:
И жмем кнопку ОК.
Для отладки -сервиса в Поставщик все готово.
3) Отладка -сервиса из Получатель.
Не закрывая конфигуратор Поставщик , запускаем Получатель в режиме «Предприятие».
Оп-пля!!! Мы впрыгнули в конфигурацию Поставщик и остановились на установленной нами точке останова в модуле -сервиса:
Хе-хе, я специально не закрывал окно Предметы отладки, чтобы увидеть наше левое подключение (закроем это окно) :).
Далее бежим по коду, смотрим интересные нам места:
И после успешного завершения метода -сервиса мы получаем возвращаемое им значение в нашу форму, разбираем его и выводим в табличное поле:
(Хе-хе, не волнуйтесь, увидевшие свои ники в списке, я не собираю компромат на вас, это просто моя дань уважения и благодарности к вам, выраженная вот в таком скромном виде 🙂 Хотя список, конечно должен был быть гораздо больше! )
4) Дополнительные инструменты отладки и тестирования.
Незаменимы при тестировании -сервисов и отладке файлов и инструменты и для FF (или же FireBugLite для других браузеров) (.
Вот как в можно из вне 1 протестировать наш -сервис Сотрудники.
Прямо здесь же можно ввести параметр и получить результат или проанализировать ошибки:
А вот отлов ошибок в :
В связи обновлением до версии 5 пришлось подправить файл sotrudniki.js из статьи Тратор’а, благодаря это было не сложно:
И результат после добавления в файл варианта 5:
Желаю всем успешного и удачного дня и хорошего настроения!
– Небольшие правки в статье;
– Разделил один архив на два: рабочие файлы и саму статью. Общий архив оставил тоже.
Обновление 12. 2019
В процессе работы часто приходится сталкиваться с ошибками 405 и 500 в HTTP сервисах. Но проблема в 99% случаев в коде сервиса. Возможно это не явно, код вас может уводить глубоко в другие модули, но решение надо искать именно там.
Сейчас у меня такие ошибки начинают и в рабочих проектах. Стоит только внести небольшое изменение которое вызывает исключительную ситуацию, как вы получите ошибку 500. Мобильный клиент ведет себя еще более странно и отловить реальную ошибку очень тяжело, особенно когда переделывает чужие формы под мобильный клиент.
В данный момент я начинаю с того, что отключаю вызов всех функций и процедур начиная со входа в обработчики HTTP сервиса и смотрю как проходят запросы. Если все хорошо, то я начинаю включать код небольшими кусочками и проверять работу сервиса. Данный метод не самый быстрый, но дает 100% результат.
Https://www. unisender. com/ru/support/about/glossary/chto-oznachaet-oshibka-404-na-sajte-i-chto-s-nej-delat/
Ошибка «Invalid command ‘ManagedApplicationDescriptor’»
Полный текст ошибки:
Ошибка связана с тем, что в файле httpd.conf отсутствует ссылка на модуль веб-расширения 1С:Предприятия, которая должна указываться в «LoadModule _1cws_module».
В этом можно убедиться выполнив команду.
Если результат пустой, то строка вида «/opt/1C/v8.3/x86_64/wsap24.so», отсутвтует — модуль не прописан.
Отредактировать конфигурационный файл httpd.conf
Создание HTTP-сервиса
Итак, создаем новый HTTP-сервис:
Корневой URL — важный параметр, входит в адрес по которому сервис будет доступен после публикации.
В соответствующем разделе создаем новый шаблон URL и метод:
У шаблона URL есть единственное свойство — шаблон. Этим свойством можно задать путь по которому будет происходить обращение к HTTP-сервису. В шаблоне можно использовать параметризованные сегменты, как на рисунке ниже (об их использовании ниже).
У метода есть свойство HTTP-метод, которое можно указать выбрав одно из следующих значений: GET, POST, PUT, DELETE, PATCH, MERGE, CONNECT, OPTIONS, TRACE, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK или Любой.
Перейдем к примеру обработчика метода, в нем я возвращаю содержимое переменной «Запрос», которая передается в обработчик:
Значения кодов ответов сервера
Код состоит из трех цифр и начинается с 1-5 в зависимости от группы, к которой принадлежит. После числового обозначения есть приписка на английском, которая поясняет его значение.
Принадлежность кода к группе определяется по первой цифре:
Коды ответов, сигнализирующих об ошибке, содержат информацию об их причинах. Отслеживать ошибки и устранять их можно по лог-файлам сервера — в логах содержится детальная информация о проблемах.
Коды ошибок клиента
Коды ответов этой группы означают ошибки по вине клиента или невозможность выдать результат, потому что на странице нет данных.
400 Bad Request
Запрос некорректен, где-то в нем есть синтаксическая ошибка, поэтому сервер не может выдать результат. Для успешного выполнения запроса нужно исправить синтаксис, обычно помогает очистка куки или кэша страниц, исправление запроса пользователем.
401 Unauthorized
Информация доступна только зарегистрированным пользователям или запаролена. Если пользователь не авторизовался, доступ к странице невозможен.
403 Forbidden
Еще одна причина — пользователь обратился к закрытому каталогу, в котором нет индексного файла. Разрешение на просмотр каталога включается в настройках сервера.
Серверу не удалось найти ресурс, который запрашивает пользователь, документа по этому адресу не существует.
Это частая ошибка, она может быть связана с тем, что пользователь ошибся в адресе страницы, у пользователя нет прав на чтение и исполнение файла, файл на сервере переместили иди удалили, корневой каталог указали с ошибкой или сервер не настроен для работы с символьными «мягкими» ссылками, которые использованы для обработки.
Код ответа 404 Not Found
Ссылки на удаленные разделы сайта будут возвращать код 404. На такие документы не нужно тратить краулинговый бюджет, поэтому в файле robots.txt запрещают роботу посещение и индексацию таких страниц.
405 Method Not Allowed
Недоступен метод, которым совершается запрос. Сервер выдает этот код для конкретных отдельных объектов на странице. К примеру, строка запроса, запускающая скрипт, отличается от запроса, который совершает пользователь.
406 Not Acceptable
Код ответа означает, что запрашиваемый файл существует, запрос сформулирован верно, но кодировка документа недоступна для расшифровки роботом.
407 Proxy Authentication Required
Этот код похож на 401 и 407, он используется, если вопрос корректен, но клиент может получить доступ к документу только с помощью авторизации через прокси. Клиент авторизуется, если прокси вернет поле с заголовком proxy-authenticate.
408 Request Timeout
Сервер возвращает этот код ответа, если в установленное время ожидания клиент не сделал ни один запрос. Код 408 не возвращается, если пользователь сам отменил запрос, или соединение оборвалось, а отправить ответ нет возможности.
409 Conflict
Код означает, что в системе конфликт: к примеру, пользователь загружает файл на сервер, где уже есть такой файл в новой версии.
410 Gone
Код ответа похож на 404 код, он означает, что документ, к которому направлен запрос, больше недоступен. Если сервер возвращает код 404, то робот еще вернется на страницу, чтобы проверить ее состояние, а в случае ответа 410 робот поймет, что страница удалена навсегда.
411 Length Required
Сервер не может принять и обработать запрос, если в заголовке content-length не указана длина контента.
413 Request Entity Too Large
Если в теле запроса слишком большой объем информации и сервер не может обработать такой большой запрос, то он возвращает код ошибки 413. Если это временная проблема, в поле Retry-After сервер укажет время, которое нужно подождать.
414 Request-URL Too Long
Аналогично с кодом 413, за исключением того, что 414 код отображается, если в запросе указан слишком длинный URL.
422 Unprocessable Entity
Сервер возвращает этот код, если он принял и распознал запрос, но в теле запроса допущена логическая ошибка, которая мешает его выполнить.
424 Failed Dependency
Если выполнение этой операции зависит от исхода других связанных с ней операций, сервер вернет этот запрос.
429 Too Many Requests
Код 429 означает, что пользователь посылает слишком много запросов за короткий временной промежуток, и сервер не может обработать такое количество.
451 Unavailable For Legal Reasons
Код отображает то же, что и 403, но с уточнениями. Он используется, если доступ к серверу заблокирован по решению суда, обычно из-за нарушения авторских прав, а также если доступ закрыт на государственном уровне.
418 I’m a teapot
Это забавный код, возвращающий ошибку «Я чайник», связан с гипертекстовым протоколом управления кофеваркой — Hyper Text Coffee Pot Control Protocol. Ошибка означает, что запрос некорректен, с помощью чайника нельзя приготовить кофе. Протокол и код этой ошибки были созданы в шутку в 1998 году к 1 апреля.
Код 418 I’m a teapot
Ошибка связана с ошибками или «опечатками» в файле настроек base.conf. Иными словами, в данном файле есть некорректные строки, которые новичку бывает сходу не так просто найти.
Исправить ошибку в строке сообщения. В данном случае допущена опечатка в имени команды.
Пример ошибочной строки. Команды forceHandler — на самом деле не существует :
Исправим файл. Укажем корректное наименвоание команды — SetHandler:
Использование системы спутникового мониторинга «Скаут»
После публикации базы на сервере, при попытке перейти по веб-ссылке базы из браузера– выдается ошибка.
Проще говоря, браузер сообщает, что не нашел такой папки публикации на сервере.
Ошибка часто связана с неправильным вводом имени базы/папки публикации.
Необходимо проверить имена папок с конфигурационными файлами базы, а также имена базы и папок в самих конфигурационных файлах.
Проверить имена публикации базы(выделено):
1. Конфигурационный файл *.conf:
2. Конфигурационный файл публикации базы *.vrd
Именно это имя необходимо вводить в браузер при проверке работы веб-сервиса: 1s-on-1c-1/base/ws/ws_1s_on_1.1cws
Информационные коды
Коды этой группы информируют о том, что сервер принял запрос и будет его обрабатывать.
100 Continue
Сервер принял запрос и удовлетворен начальными сведениями. Процесс обработки будет продолжен.
101 Switching Protocols
Сервер одобрил переключение типа протокола, которое запросил пользователь. Код используется, когда сервер предлагает перейти на новую версию HTTP. В поле Update будут перечислены доступные протоколы, пользователь может выбрать один из них.
102 Processing
Сервер сигнализирует, что принял запрос, но на обработку требуется больше времени. Клиенту не нужно разрывать соединение, он должен сбросить таймер и дождаться следующей команды.
Прокси сервер
1) Запустить Internet Explorer от имени пользователя, под которым работает rphost
2) В меню Свойства браузера (Свойства обозревателя) на закладке Подключения нажать кнопку Настройка сети
3) Если в настройках указано использование прокси-сервера, которая не предусмотрена политикой безопасности (кто-то когда-то установил и забыл) – отключить использование прокси-сервера, сняв соответствующий флаг
4) Если использование прокси действительно предусмотрено, нужно разрешить прямое обращение к ресурсам, на которые пытается обратиться платформа для валидации сертификата, нажав кнопку Дополнительно и указав данный ресурс в качестве исключения для прокси-сервера
Креативные 404 страницы – вред или польза?
Смешное оформление 404 страницы – это красиво и оригинально, но не стоит слишком сильно увлекаться. Не стоит забывать, чтобы пользователю в первую очередь необходимо решить какие-то задачи на вашем сайте, а не зависать на 404 странице, Вы должны максимально упростить и помочь ему в достижении его целей.
Что означает ответ 404
Error 404 Not Found отображается по-разному: «HTTP 404 не найден», «Ошибка 404 Not Found», «404 Страница не найдена». Смысл надписи всегда остаётся тем же: страница отсутствует либо просто не работает. Not Found в переводе означает «не найдено».
Ошибка 404 — классический код ответа по протоколу HTTP. Он свидетельствует, что связь с сервером установлена, но информации по заданному запросу нет.
Однако если просто ввести в поисковую строку произвольный набор символов, то браузер не покажет ошибку 404 Not Found — появится сообщение, что установить соединение с конкретным сервером невозможно.
Разберёмся в техническом формировании ответа Error 404 Not Found.
Техническая сторона вопроса. При связи по HTTP браузер запрашивает указанный URL и ждёт цифрового ответа. То есть любой запрос пользователя направляется на сервер размещения искомого сайта. Когда браузеру удаётся связаться с сервером, он получает кодированный ответ. Если запрос корректный и страница найдена, отправляется ответ с кодом 200 OK, что соответствует благополучной загрузке. При отсутствии страницы отправляется ответ об ошибке.
Что значит код «404». В ответе 404 первая четвёрка указывает на то, что запрос был чрезмерно длительным или в самом адресе была ошибка. Ноль предполагает синтаксическую неточность. Завершающая цифра кода отображает конкретную причину ошибки — «4» означает отсутствие данной ссылки.
Какие ещё ошибки бывают. Ошибку 404 не нужно путать с другими ответами, которые указывают на невозможность связи с сервером. Например, ошибка 403 сообщает, что доступ к URL ограничен, а ответ «Сервер не найден» свидетельствует, что браузер не смог обнаружить место размещения сайта.
Google на 404 странице сообщает о возможных причинах ошибки
Создание, публикация и отладка
В платформе версии 8.3.5 появилась возможность создавать HTTP-сервисы. Как и «старые» SOAP web-сервисы, HTTP-сервис позволяет получать/изменять данные, но при этом, как утверждает компания 1С, HTTP-сервисы потенциально позволяют упростить создание клиентских приложений, уменьшить объем передаваемых данных и вычислительную нагрузку, все это особенно для мобильных устройств.
В этой статья я постараюсь рассказать о том, как создавать, отлаживать и использовать HTTP-сервисы в 1С.
Начнем с того, что для создания HTTP-сервиса нам необходим веб-сервер, например Apache 2.2 (начиная с версии 8.3.8 и Apache 2.4 подойдет). Описывать установку веб-сервера думаю нет необходимости.
После выполнения всех настроек файлов публикации базы или сервиса 1С:Предприятия. При попытке запустить веб-сервер — выдается ошибка и веб-сервер не запускается.
Необходимо проанализировать более подробное описание ошибки. Его можно получить следующим образом.
В результате выполнения команды будет выдано более подробное сообщение об ошибке.
Разбор, которых приведен в статье далее.
Как сделать страницу 404 полезной
Грамотно оформленная страница с ошибкой Error 404 Not Found — действенный инструмент конвертации посетителей. Ограничений по использованию страницы с ошибкой 404 нет. При этом практически все CMS позволяют настраивать дизайн этой страницы.
Что публиковать на странице 404:
При оформлении страницы-ошибки желательно опираться на рекомендации поисковиков:
Главное — по возможности отказаться от стандартной страницы 404. Подумайте, как привлечь внимание пользователя. Расскажите ему об отсутствии искомой страницы и предложите взамен что-то полезное или интересное.
Работа с HTTP в 1С 8. 2 и 8
В этой статье я попробую рассказать о том, какими средствами располагает технологическая платформа для работы с протоколом HTTP. В начале будет немного общей информации, а затем конкретные примеры. Отмечу, что в статье используется технологическая платформа версии 8.3.12.1595.
HTTP-сервис «Товары»
HTTP-сервис «Товары» написан в REST-стиле. Он позволяет получать и удалять элементы и группы в справочнике товаров. Доступ к элементу осуществляется с помощью его пути в иерархии.
Например, для того чтобы получить информацию о товаре «Ряженка» с кодом 000000027, входящем в группу «Молочные» с кодом 000000099, которая входит, в свою очередь в группу «Продукты» с кодом 000000011, в браузере надо будет набрать http:// /hs/Products/000000011/000000099/000000027. Если база опубликована по пути http://localhost:8090/Platform8Demo/, то путь будет:
http://localhost:8090/Platform8Demo/ hs /Products/000000011/000000099/000000027.
Из чего состоит путь? Рассмотрим по частям:
В нашем случае у сервиса один дочерний объект шаблон URL. В свойстве «Шаблон» этого объекта записана строка “/*». Звездочка – это специальное значение, указывающее на то, что к данному шаблону подходят любые URL. В нашем случае необходимость использования такого шаблона (т.е. по сути отказа от ограничения URL) обусловлена произвольной глубиной иерархии товаров.
У нашего шаблона URL имеются два дочерних объекта, соответствующих HTTP-методам GET (получение) и DELETE (удаление). Именно в них указаны обработчики, которые будут вызываться при обращении к HTTP-сервису.
Для обработки запроса с использованием HTTP-метода GET (а именно такой будет создан, если вставить указанные выше URL в браузер) используется функция ПутьКТоваруGET. Рассмотрим эту функцию немного подробнее:
Сформированное XML-представление используется в ответе сервиса:
Как настроить ответ сервера?
Если Ваш сервер или CMS не настроены атоматически, то придётся это сделать Вам самим – добавьте в htaccess строчку:
ErrorDocument 404 https://www. site. ru/404.php
Теперь, когда пользователь введёт неверный адрес, то он будет направлен на этот адрес. Страница может располагаться где угодно, но мы для примера поместили ее в корне сайта: /404.php.
404 ошибка сервера в PHP
Велосипеда изобретать не надо – существует специальная функция header, которая успешно поможет Вам это сделать.
Header(«HTTP/1.0 404 Not Found»);
Как обеспечить ответ 404 Not Found?
Если сайт функционирует на какой либо из популярных CMS, то проблем с ответами сервера быть не должно. Тем не менее следует убедиться, что сервер обрабатывает все запросы корректно. Если при запросах несуществующих страниц возвращается код 200 OK, либо другой, отличный от 404 Not Found, то нужно обратиться в техническую поддержку хостинг-провайдера (если вы не разбираетесь в серверных настройках).
HTTP-сервис “Товары”
HTTP-сервис “Товары” написан в REST-стиле. Он позволяет получать и удалять элементы и группы в справочнике товаров. Доступ к элементу осуществляется с помощью его пути в иерархии.
- http://localhost:8090/Platform8Demo/ – путь публикации информационной базы
- hs – обязательный сегмент пути, сообщающий серверу, что будет происходить работа с http-сервисами
- Products – строка, идентифицирующая конкретный веб-сервис. Задается свойством “Корневой URL http-сервиса” объекта метаданных веб-сервиса
- 000000011/000000099/000000027 – путь внутри сервиса. Все допустимые пути для данного сервиса определяются совокупностью дочерних объектов метаданных “Шаблон URL”.
В нашем случае у сервиса один дочерний объект шаблон URL. В свойстве “Шаблон” этого объекта записана строка “/*”. Звездочка – это специальное значение, указывающее на то, что к данному шаблону подходят любые URL. В нашем случае необходимость использования такого шаблона (т.е. по сути отказа от ограничения URL) обусловлена произвольной глубиной иерархии товаров.
- Функция принимает единственный параметр “Запрос”, это объект типа HTTPСервисЗапрос, содержащий всю нужную нам информацию о выполняемом вызове.
- Дальнейший код функции ищет элемент справочника по цепочке “00000011/000000099/000000027”, используя объекты “1С:Предприятия”.
- Если в какой-то момент следующее звено цепочки не находится, то формируется ответ сервиса с кодом 404, знакомым каждому пользователю веб-браузера.
Копировать в буфер обмена
Ответ HTTPСервисОтвет
Ответ HTTPСервисОтвет
ОтветУстановитьТелоИзСтрокиСтрокаXML
// Помогает клиенту понять, что за данные к нему пришли
// Браузеры, например, применят удобную подсветку XML-синтаксиса
ОтветЗаголовкиВставить
Обработка HTTP-метода DELETE происходит в функции ПутьКТоваруDELETE и мало чем отличается от обработки запроса с использованием HTTP-метода GET. Стоит обратить внимание на то, что в случае DELETE используется код ответа 204, а не 200. Код ответа 204 также свидетельствует об успешном выполнении операции на сервере, но сообщает клиенту, что сервер не посылал в ответ никаких данных в теле запроса.
Предприятие при подключении через веб сервер, Linux. «Selinux policy enabled
При попытке запустить клиента 1С:Предприятие через веб-сервер (строка подключения вида: «ws=»http://1s-on-server/bast»;») — сеанс не запускается.
Но при этом, таже самая база — запускается успешно при прямом подключении к серверу 1С:Предприятия (строка подключения вида Srvr=»1s-on-server»;Ref=»base»;).
1. Убедиться, что selinux, действительно, работает.
Если видим Enforcing, значит переходим к следующему пункту.
2. Отключить selinux:
3. Проверить, что настройка выполнена.
Permissive – включен, но ничего не запрещает.
Enforcing – включен, работает, и запрещает.
Ошибка 405 и 500 в HTTP сервисе 1С. Поиск и устранение.
Добрый день, хотел поделиться с вами результатом преодоления этих ошибок при работе с http сервисами 1С. С данной ошибкой мне пришлось столкнуться при переписывании мобильного приложения с web сервисов на http. Ошибка возникала при отправке http сервису POST запроса.
Как ошибка 404 влияет для SEO?
Если при запросе несуществующей страницы сервер возвращает код 200 OK, то это сигнализирует поисковым системам о том, что страница существует. Такая техническая оплошность мешает корректно индексировать сайт и может негативно отразиться на его ранжировании.
Страницы 404 не должны индексироваться поисковыми системами. Убедитесь, что ваш веб-сервер отправляет код статуса HTTP 404
Одна из распространенных ошибок заключается в замене сообщения об ошибке 404 (страница не найдена) для несуществующих страниц на страницу-заглушку, которая возвращается с кодом ответа 200 (ОК). В этом случае поисковая система считает, что страница с некорректным адресом существует, и не удаляет ее из своей базы. Это приводит к более медленному индексированию полезных страниц на сайте.
Для чего нужна 404 страница?
1. Поисковому роботу необходимо сообщить, что такой страницы не существует, для этого используется 404 код ответа сервера. Это очень важно, чтобы не плодились дубли и не размывать релевантность страниц в индексе поисковых систем.
Проверить ответ это очень просто, наберите несуществующий адрес страницы тут – https://bertal. ru/.
2. Пользователю необходимо сообщить, что запрашиваемой страницы больше (или вообще) не существует, и предоставить возможность работать с сайтом дальше.
Как проверить код ответа сервера
Посмотреть код ответа на странице можно бесплатно за пару кликов. В браузере информация находится на панели разработчика: в Google Chrome для вызовите панель горячей клавишей F12, откройте вкладку Network и обновите страницу.
Результаты просмотра кода в браузере
Для просмотра кода есть браузерные расширения: HTTP Headers для Google Chrome, HTTP Header для Opera.
Результаты проверки инструментом
Инструмент проверки заголовков сервера от PR-CY определит HTTP статусы сайта и доменного имени.
Новый(Тип(«WSОпределения»), Параметры) — откуда настройки прокси?
Определение: “404 ошибка сервера (not found) — самая распространенная ошибка при пользовании Интернетом, основная причина — ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI.”