Посторонние символы при посещении не существующих страниц
Drupal 6.10. Чистый. Т.е. только что установленный без каких-либо доп. модулей. Установлен русский.
При обращении к несуществующей странице (т.е. ошибка 404) над всем содержимым (перед открывающим тегом , который написан в самом начале page.tpl.php) страницы выводится некое шестнадцатиричное число (4-ёх разрядное), по величине своей оно близко к размеру сгенерированной html-страницы.
(Например, показывает число 5946, что в 10-ричной СС будет 22854, размер page.tpl.php - 26098, а размер сгенрированной html-странички 23328, при уменьшении размера сгенирированной страницы, это число пропорционально уменьшается.)
Пытался разобраться откуда это число взялось.
Выяснил следующее: ни от темы, ни от содержимого tpl-файлов это не зависит. Зависит от размера сгенированной html-страницы. Если больше 8000 байт - есть посторонние символы, если меньше - нет. (проверял - заполнял page.tpl.php одним много раз повторяющимся символом (английской буквой), если размер получившейся html-ки 8000 байт, то нет посторонних символов, если 8001 - то есть и потом уже как не увеличивай размер - они есть. Делал так: в page.tpl.php писал <?echo $content; ?>, а в node.tpl.php заполнял многократно повторяющейся буквой, чтобы размер html-ки был не более, а потом более 8000 байт - убедился что от того как генерируется страничка это не зависит, зависит лишь от размера сгенирированной).
Этих 4-ёх посторонних символов в IE 7 ни прикаких условиях нет, а в Опере 9 и Мозилле 3 - есть при превышении страницей размера 8000 байт - при всех условиях (в смысле чтобы я ни делел - они есть).
Настройки кэширования, сжатия - менял, кэш чистил. Ничего не меняется. Эксперементировал более 6 часов...
Ставил чистый друпал 6.10 и на нём в теме garland проверял.
В настройках друпала прописывал особую страницу для ошибки 404 - ничего не меняется.
На локалке под денвером - ничего подобного не возникает, даже если сгенерированная страница - полмегабайта.
Если я захожу на существующие страницы (т.е. не ловлю ошибку 404) - никаких посторонних цифр нет. Ни в одной из tpl-ек таких цифр нет. Удалял все tpl-ки из темы кроме page.tpl.php, а её используя шестнадцатиричный редактор файлов - заполнял повторяющимся определённым байтом. Если размер был больше 8000 байт - были в начале посторонние символы. (в файле page.tpl.php их точно нет и вывести их там нечему)
Хостиг - Джино (jino.ru). Сменить хостера могу без проблем. Ответ - смени хост, пожалуйста, не говорите.
В чём может быть причина? Откуда могут появиться эти цифры-буквы?
Большое спасибо.
- Блог
- Войдите или зарегистрируйтесь, чтобы отправлять комментарии
Комментарии
такая же байда кстати, в онлайн-версии сайта наблюдается. Разбираться увы нету времени, посмотрел на очередную стотыщьпяццотую маленькую какашку, любезно подкинутую друпалом, да и плюнул, до лучших времен так скыть... Ядро 6.7-dev.
никогда не сталкивался с такой проблемой за 3 года работы с друпалом. Хостинги были петерхост, руцентр, сейчас у gor-а.
Есть такой-же вопрос на 5х... рыл-рыл... не нашел откуда выводится. Актуально.
Хех:) Уже трое с подобное проблемой...
kosilko, argon у вас кто хостер для проектов, у которых такая проблема?
Кстати, посмотрите в style.css в самом начале.
Вот в теме Analytic в версиях 1.0 - 1.2 в начале css были посторонние символы.
Не знаю связано это с текущей проблемой или нет. Просто заметил.
Архив распоковывал winrarom. При просмотре в winrare, блокноте и wordpade символов не наблюдалось.
При просмотре уже распакованного через Far символы присутствовали.
Подозреваю что это как то связано с архиваторами или их версиями.
Эти символы записываются в начало файла при сохранении из notepad+ файла в формате UTF-8.
У меня из-за них были похожие глюки на сайте.
Просто стер их и все прошло.
mchost.ru
Сейчас проверил.
Случай номер РАЗ:
URL: /ffgывы
Выдало число cbed, калькулятор говорит что это 52205 в десятичной системе. Размер страницы - 52218 байт.
Случай номер ДВА:
URL: /выва
Выдало число cbf3, (т.е 52211). Размер страницы - 52224 байт.
Случай номер ТРИ:
URL: /dfkgjdrjklgsdjkhf893475/dfdf/dfdfdf/dfdf/sdjkvfnsdjkghjksdfhvgsdfjkg
Выдало число cc53, (т.е 52307). Размер страницы - 52320 байт.
Во всех случаях разница между числом и размером страницы 13 байт. Число, кстати, выводится с переносом строки (0D,0A).
Что характерно, я уже не помню что там намутил, но у меня друпал вместо сообщения о ненайденном документе выводит главную страницу.
Хы-хы. Да, и еще. В конце при этом ненавязчиво выводится цыферка НОЛЬ и уже с одним до и двойным переносом строки после (0d,0a, "0" , 0d,0a,0d,0a)
В итоге имеем ровно 13 байт мусора, то есть число вверху страницы - не что иное, как размер, который должен быть у страницы, если бы она выводилась без этого мусора.
P.s. только что выяснил, что размер страницы меняется всвязи с "?destination=урл", который прописывается в form action=... одного из блоков.
Ага, у меня тоже самое.
происки внеземных цивилизаций
не иначе
P.S.
А у меня, друпал после переезда из папки ("2") в корень, в собственной странице для ошибок писал "2"
Эти символы есть во многих CSS-файлах и не только в темах друпала. Но не думаю что они генерируют цифры.
2Green Chest, заметила как-то в теме (для WP), в внизу шаблона index (или foter) в закомментированной строчке был вставлен php код для подсчета размера, кол-ва запросов к базе и время их выполнения. Т.к. это все дело было закомментировано, естественно на странице не выводилось, а вот при просмотре html можно было посмотреть всю эту статистику.
Может и у вас что-то подобное в теме?
Эксперименты которые я провёл и о которых написал в первом сообщении этой темы исключают то о чём вы говорите.
Никакие ccs-ки не подключаются вообще! Вывод заголовков из темы убран, всё убрано. Файлы сохранены в notepad++ в utf-8 без BOM и просмотрены в шестнадцатиричном редакторе - ни в начале, ни в конце файлов темы нет посторонних символов (тем кто предлагает такой вариант - а почему же они тогда только при посещении не существующей страницы появляются? И почему их не показывает интернет експлорер?).
worona, если у вас сайты на jino.ru, то вы возможно такого не видели, потому что код html-страниц генерируемых при посещении не существующих адресов не превышает у вас 8000 байт.
Сдается что это хостер виноват. Дело не в Друпале.
У меня на Jino.ru 4 сайта стоят - никогда такого не видел...
надо эти странички не просматривать, а сохранить на диск и уже там редактором посмотреть. может эти цифры идут до хедера, поэтому IE их не отображает. или ещё какая причина.
В сгенерированных для IE страниц посторонние символы отстутствуют вообще.
может здесь собака порылась?
когда урл правильный:
и когда ошибка 404:
Я так понял в http-заголовках при не правильном url идёт что-то не так.
Вы дальше свою мысль продумывали? Что можно сделать?
я так думаю, все дело в chunked и/или его обработке. В RFC написано, что при таком методе передачи контента он рубится на куски, и в начале каждого куска передается число содержащее размер оного куска. Почему во втором случае мы имеем не "chunked", а "chunked, chunked" - я не совсем понимаю. Возможно, таким способом говорится, что кусков два? А второй кусок при этом, во втором случае имеется равным нулю... А возможно, что "chunked, chunked" - это кривовато или экзотично, и не все броузеры это понимают? Или броузеры некорректно обрабатывают пакет нулевой длины... У меня, кстати, и в ИЕ7 тоже самое, что и в FF/opera. Green Chest, у вас на хостинге что стоит в роли сервера?
а вот ответ 404 от локального сервера, с локальной копией сайта. Слово chunked - один раз.
Server Apache/2.2.8 (Unix) PHP/5.2.6
X-Powered-By PHP/5.2.6
Expires Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified Wed, 11 Mar 2009 09:25:13 GMT
Cache-Control store, no-cache, must-revalidate, post-check=0, pre-check=0
Keep-Alive timeout=5, max=100
Connection Keep-Alive
Transfer-Encoding chunked
Content-Type text/html; charset=utf-8
Информация о хосте:
Операционная система: Linux version 2.6.18-92.1.22.el5
Версия Perl: 5.8.8
Версия PHP: 5.2.6
Версия MySQL: 5.0.67
Путь к Perl: /usr/bin/perl
Путь к PHP: /usr/local/bin/php
Путь к sendmail: /usr/sbin/sendmail
Встроенные модули Apache:
core
mod_authn_file
mod_authn_default
mod_authz_host
mod_authz_groupfile
mod_authz_user
mod_authz_default
mod_auth_basic
mod_include
mod_filter
mod_log_config
mod_logio
mod_env
mod_expires
mod_headers
mod_setenvif
mod_ssl
prefork
http_core
mod_mime
mod_status
mod_autoindex
mod_asis
mod_info
mod_suexec
mod_cgi
mod_negotiation
mod_dir
mod_actions
mod_alias
mod_rewrite
mod_so
На локалке стоит денвер. Т.е. апач под виндой.
ясно, думал что из-за nginx
Аналогичная проблема возникла при установке на своем сервере Invision Power Board'а. При этом при попытке включения в нем GZIP-сжатия страницы вообще перестает отображаться, ссылаясь на:
Предполагал что число как раз и связано с GZIP'ом. На сервере стоит связка nginx + apache, проблема точно не в nginx, apache уже отдает страницу с кривым числом.
После долгих изысканий, смысла которых приводить тут нет проблема решилась добавлением данной строку в конфигурацию Apache:
AddOutputFilterByType DEFLATE text/html text/plain text/xmlСуть моей проблемы была -- неверно или вообще не сконфигурированный mod_deflate, который отвечает как раз за сжатие страницы. В итоге странные числа в начале и в конце страницы у меня пропали.
На shared-хостинга возможно поможет данная строка в .htaccess:
SetOutputFilter DEFLATEУ меня появилась такая же проблема. Появилась она после того, как на сервере перешли на связку apache+nginx. Причем данная проблема возникла только на форуме IPB (вроде). Факт того, что именно после ввода nginx появилась данная проблема понятен, но не понятно, как избавиться.
Та же проблема.
Только не на 404 (page not found) а на 403 (access denied)
Причем стоит довольно большое количество сайтов на одной и той же конфигурации веб-сервера. Проблема проявляется на некоторых из них устойчиво.
В том числе и в IE. Причем у него жутко съезжает форматирование страницы в отличие от прочих браузеров.
Символы с размером данных идут после http заголовка до
mod_deflate отключен
С размером страницы связано?
Старая проблема. Кто то нашел решение?
Проблема в апаче, в частности с кодировкой чего-то там, помоему связано с сжатием. Точнее не могу сказать, то письмо от хостера, где мне подробно объяснили, затерялось. Они (хостеры) просто отключили эту кодировку и всё стало нормально. Всё что могу сказать, я не юникс-администратор к сожалению.
Проблема изменилась, на странице 404 появлялись непонятные символы и пропадали primary links, я связался с хостером, он мне сделал следуещее:
Все отлично, но primary links так и не вернулись. Что это может быть?
P.S. Это происходит на двух сайтах под управлением друпала, на одном сервере, на этом же сервере стоят и другие сайты на друпале, но там все в порядке!
их и там и не было никогда, это стандартное поведение друпала http://drupal.org/project/blocks404