- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Здравствуйте.
Итак проблема в кириллическими ЧПУ и некотороыми роботами (в частности яндекса).
А проблема в том, что этим некоторым сервер упорно выдаёт 406 ошибку, хотя сам скрипт запускается и срабатывает.
При этом в браузерах всё работает, пока ошибок не было найдено ни у кого.
Приём ошибка выдаётся только для кириллических URL - с латинскими проблем нет.
Первоначально я считал что проблема в кодировках - в частности от браузеров URL приходит всегда в скрипт в utf-8 кодировке и его нужно перекодировать в cp1251.
В службе поддержки одной из систем, чей робот возвращает 406 ошибку мне сказали что запрос URL отправляется в cp1251 кодировке. (и действительно, была с этим проблема, но опять же проблема была в том, что тогда страница выдавалась не та, которая запрошена, а всегда главная)
Ну бог с этим, переделал скрипт и этот баг был исправлен.
Так же ещё я 2-жды (для надёжности, нихай с ним уже будет лишний раз) указываю кодировку в которой работает сайт: есть и header('Content-Type: text/html; charset=windows-1251'); и <meta http-equiv="Content-Type" content="text/html; charset=windows-1251">
Однако проблема осталась. При этом сам скрипт запускается! (в частности я сам пока записываю в текстовый файл что прихоисдит и что на выходе). И выяснилось что скрипт по крайней мере правильно формирует все sql запросы и получает содержимое страницы из БД. Но сервер всё равно отправляет 406 ошибку.
При этом лог-файл ошибок сервера пуст.
Пояндексив по этому вопросу я узнал что в этом виновата от части система фильтрации атак самого апача ModSecurity. (хотя её такая избирательность мне не совсем понятна).
Но отключить её - прописав в .htaccess инструкцию "secfilterengine Off" не получилось - 500 ошибка и запись в лог файле:
Это я так понимаю результат того, что запрещено изменение этой инструкции через .htaccess.
В службе поддержки Яндекса мне ответили на это следующее:
документов в типе text/html. То есть, по какой-то причине, сервер, отдавая
text/html, считает, что он не может быть обработан роботом и формирует ответ
406 Not Acceptable.
Браузерам (например FireFox) отдается страница с кодом 200, так как они
отправляют запрос, который предполагает, что сервер может вернуть любой тип
контента, если нет возможности вернуть text/html, application/xhtml+xml или
application/xml (Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8).
Например:
Accept: text/html
Host: www.webforever.info
User-Agent: Yandex/1.01.001 (compatible; Win16; I)
HTTP/1.1 406 Not Acceptable
Date: Mon, 19 Oct 2009 09:03:09 GMT
Server: Apache/2.2.13 (Unix) mod_ssl/2.2.13 OpenSSL/0.9.8e-fips-rhel5
mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 PHP/5.2.10
X-Powered-By: PHP/5.2.10
Set-Cookie: PHPSESSID=651d2143af6233242b19b29dfb0c674c; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: auth=deleted; expires=Sun, 19-Oct-2008 09:03:08 GMT; path=/;
domain=webforever.info
Transfer-Encoding: chunked
Content-Type: text/html; charset=windows-1251
А теперь вопрос. Как может сервер такое возвращать? В частности последняя строка:Content-Type: text/html; charset=windows-1251 означает как раз то, что всё возвращается в том формате в котором нужно. Или я что-то не совсем понимаю?
Думаю тут есть специалисты, кто в серверах хорошо разбирается и обьяснит мне как можно устранить такую проблему? (ну кроме отказа от кириллицы в URL или писать только url, обработанный через urlencode())
Заранее большое спасибо.
кирилиица в URL совместима нормально только с utf-8. Откажитесь от cp1251 и будет счастье
Мда, на словах это конечно легко. Но перевести все страницы и БД в utf-8 из cp1251 весьма напряжно будет.
Ну чтож, остаётся только пробовать и надеятся что проблема именно в этом. Спасибо за совет.
КИЉЕР‡;5668860']Мда, на словах это конечно легко. Но перевести все страницы и БД в utf-8 из cp1251 весьма напряжно будет.
Дамп базы в текстовый файл - конвертим файл из вин в утф - в чем напряг?
КИЉЕР‡;5668860']Мда, на словах это конечно легко. Но перевести все страницы и БД в utf-8 из cp1251 весьма напряжно будет.
Ну чтож, остаётся только пробовать и надеятся что проблема именно в этом. Спасибо за совет.
Урл распарсить самое простое -
А Ваш сайт вообще кривой: cессия не стартуе на главной и все знаки - точки.ewg777,
да кривой т.к. сейчас как раз занимаюсь перекодированием.
malls,
Да с БД проблем нет, но нужно ещё немало файлов в другую кодировку перевести. и скрипты немного корректировать, т.к. в некоторых местах преобразованвывается из utf8 в cp1251
кирилиица в URL совместима нормально только с utf-8
какое отношение имеет кодировка ответа сервера к ниписанию URL?????
ОШИБКА 406 - Ресурс, указанный клиентом по данному URL, существует, но не в том формате, который нужен клиенту. Вместе с этим кодом сервер выдает заголовки Content-Language, Content-Encoding и Content-Type.
Самое интересное, что эта проблема возникает именно у PHP. Возможно это особенности реализации. Попробовал читстый HTML - все оки.
Возможно, что бот яши, видя кириллический URL, меняет заголовок запроса (ведь уже было, что он перестал нормально отрабатывать протокол HTTP1/0.)
PS URL - все таки должен оставаться таким, как он был создан, независимо от решений нашего глубокоуважаемого Президента
Utf-8 кодировка не помогла, а только добавила проблем (например функции обработки строк некооректно работают.. в utf-8 ведь больше байт)((
Да и у меня проблема я всё-таки думаю в сервере.
А именно, в том, что разные роботы самому серверу посылают url в разной кодировке.
И те, кому возвращается код 406, они как раз в cp1251 посылают url.
Это видно даже по статистике в панели управления.
Например, от гугля приходит такое:
и получает нормальный 200 код ответа.
А яндекс посылает следующее:
и получает то что и запросил (что-то нехорошее то есть).
Так что боюсь что мне придётся либо отказываться от кириллицы (чего делать не хочу).
Либо ориентироваться только на Гугля, забить на яндекс, ждать пока закончится этот хостинг (ну и попутно сайт до ума довести) а потом найти новый хостинг где не будет таких проблем.