Я создал свою собственную страницу с ошибкой «404 страница не найден» на веб-сайте TYPO3 и реализовал ее через /typo3conf/LocalConfiguration.php следующим образом, используя URL-адрес Speaking URL :Страница ошибки TYPO3 7.6: 404: HTML, завернутый в числа

return [ 
    ... 
    'FE' => [ 
     ... 
     'pageNotFound_handling' => '/page-not-found/', 
    ] 
]

Теперь, когда я звоню несуществующую страницу, получает отображается страница ошибки, но есть 4-значное число буквенно-цифровое (шестнадцатеричная насколько я видел сейчас) ПЕРЕД исходного HTML кода и a «0» ПОСЛЕ. Пример (число в начале отличается после того как большинство из перезагрузок):

37b3 
<!DOCTYPE html> 
... 
</html> 
0

При вызове страницы ошибок URL самой страницы правильно возвращенное без этих чисел.

Наличие активированного или дезактивированного расширения RealURL не имеет значения.

Большое спасибо!

источник

2017-01-02 clive beckett

Я добавил полное описание из установочного инструмента, и я думаю, мы могли бы найти там решение.

Как TYPO3 должен обрабатывать запросы на несуществующие/доступные страницы.

пустым (по умолчанию)

Следующая видна страница вверх в дереве страниц показано.
'истинный' или '1'

сообщение об ошибке показано.
Строка

В статических HTML-файл, чтобы показать (читает контент и выходы с правильными заголовками), например, notfound.html или http://www.example.org/errors/notfound.html.
Приставка "перенаправление"

Если с префиксом "перенаправлением:" он будет перенаправлять на URL/скрипт после префикса.
Приставка «ReadFile:»

Если с префиксом «ReadFile», то он будет ожидать, что остальные строки быть HTML-файл, который будет считан и выводимый непосредственно после того, как маркер «### CURRENT_URL ### "заменен на REQUEST_URI и ### REASON ### с текстом причины, например: READFILE:fileadmin/notfound.html.
Префикс "USER_FUNCTION:"

Если префикс "USER_FUNCTION:" функция вызывается пользователем, например, USER_FUNCTION:fileadmin/class.user_notfound.php:user_notFound->pageNotFound, где файл должен содержать класс user_notFound по методу pageNotFound() внутри с двумя параметрами $param и $ref.

Что вы настроили:

можно передать строку, таким образом, TYPO3 ожидает найти файл - который вы не имеете, потому что это больше похоже на URL.

От чего вы пытаетесь достичь Я бы пошел с REDIRECT:/page-not-found/.

Благодарим за внимание к этому извне, я удалю конфигурацию string из ядра, так как не имеет смысла больше людей путешествовать в эту ловушку.

источник

2017-01-02 10:58:57

Я редактировал код в исходном вопросе. Обратите внимание, что число в начале составляет 37b3 большую часть времени, но не всегда. Но это всегда было 4 цифры/символы. Спасибо! –

ОК. Путь/page-not-found/- физический путь на сервере или вы хотите, чтобы этот путь был запущен TYPO3? –

Это страница, созданная в TYPO3. Как сказано: я пытался с и без RealURL, и я также назвал страницу напрямую. Ошибка появляется, когда я вызываю несуществующую страницу - [www.digs-bb.de/foo/bar/](http://www.digs-bb.de/foo/bar/) - но страница выглядит отлично когда я называю это напрямую: [www.digs-bb.de/page-not-found/](http://www.digs-bb.de/page-not-found/) –

Короче говоря: измените следующую строку в разделе FE вашего LocalConfiguration.php:

'pageNotFound_handling' => '/your404page.html',

'pageNotFound_handling' => 'REDIRECT:/your404page.html',

источник

2017-03-28 15:01:26 Jan

Добро пожаловать в [so]. Пожалуйста, уточните немного о том, почему ** это нужно сделать таким образом, поскольку будущие читатели, возможно, не смогут понять ваш ответ. – Fairy

_why_ объясняется в длинном ответе выше, о котором я говорил. – Jan

Причина

Фактическая причина представляет собой сочетание фрагментированного Содержания -Encoding и TYPO3 не могут декодировать это в некоторых случаях. В вашем случае не найденный обработчик страницы в конце концов использует GeneralUtility::getUrl() для извлечения страницы с ошибкой.

Если у вас есть [SYS][curlUse], он будет использовать cUrl для извлечения страницы, и нет проблем.

Если у вас нет [SYS][curlUse], он откроет сокет, прочитает заголовки, а затем прочитает остальную часть тела. Если веб-сервер использует «chunked» Content-Encoding, тело будет содержать блоки данных, и каждый блок начинается с строки с длиной в шестнадцатеричном формате. Содержимое заканчивается пустым блоком (с, конечно, строкой с длиной «0»). cUrl, очевидно, знает, как декодировать помеченные данные.

getUrl() сам по себе не знает, как обращаться с фрагментированными данными и использует контент, как и содержание страницы.

В TYPO3 8 LTS библиотека guzzle используется для обработки HTTP-запросов. В коде жужжания я ничего не могу найти о обработке данных с каналами. Guzzle проверяет наличие внутреннего расширения cUrl PHP и использует его как предпочтительный транспорт. В большинстве установок cUrl присутствует, и поскольку это автоматически декодирует записанные данные, проблема не видна. Я должен проверить жульничество с PHP, у которого отключен cUrl, чтобы узнать, присутствует ли проблема в v8/master.

Обход/решение

Если расширение Curl PHP включена в установке вы можете просто установить [SYS][curlUse] в Install Tool. Цифры вокруг содержимого страницы 404 исчезнут.

источник

2017-06-21 19:12:45

Спасибо за это! Он работает ... но не так, как я ожидал: он перенаправляет даже с '' pageNotFound_handling '=>'/page-not-found/', ' , не указывая явно« REDIRECT:/page-not-found/' –

Страница ошибки TYPO3 7.6: 404: HTML, завернутый в числа

ответ

Как TYPO3 должен обрабатывать запросы на несуществующие/доступные страницы.

Что вы настроили:

Причина

Обход/решение

Смежные вопросы