TYPO3 7.6: 404 error page: HTML wrapped in numbers

Question

TYPO3 7.6: 404 error page: HTML wrapped in numbers

1.6k views Asked by clive beckett At 01 January 2025 at 08:23

I created my own “404 Page not found” error page on a TYPO3 website and implemented it via the /typo3conf/LocalConfiguration.php as follows, using the page’s Speaking URL path:

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

Now when I call a non-existing page, the error page gets displayed but there is a 4-digit alphanumeric number (hexadecimal as far as I’ve seen by now) BEFORE the HTML source code and a “0” AFTER it. Example (the number in the beginning is different after most of the reloads):

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

When calling the error page URL itself the page is returned correctly without those numbers.

Having the RealURL extension activated or deactivated does not make a difference.

Thanks a lot in advance!

Original Q&A

There are 3 answers

Jigal van Hemert On 21 June 2017 at 19:12

Cause

The actual cause is a combination of chunked Content-Encoding and the TYPO3 not being able to decode that in some cases. In your case the page not found handler eventually uses GeneralUtility::getUrl() to retrieve the error page.

If you have [SYS][curlUse] enabled it will use cUrl to retrieve the page and there is no problem.

If you don't have [SYS][curlUse] enabled it will open a socket, read the headers and then read the rest of the body. If the webserver uses "chunked" Content-Encoding the body will contain blocks of data and each block starts with a line with the length in hexadecimal format. The content ends with an empty block (with of course a line with the length "0"). cUrl apparently knows how to decode chunked data.

getUrl() itself does not know how to handle chunked data and uses the content as is as the page content.

In TYPO3 8 LTS the guzzle library is used to handle HTTP requests. In the guzzle code I can't find anything about handling chunked data. Guzzle will check if the cUrl PHP extension is present and use that as preferred transport. In most installations cUrl is present and since this decodes chunked data automagically no problem is visible. I have to test guzzle with PHP that has cUrl disabled to see if the issue is also present in v8/master.

Workaround/solution

If the PHP extension cUrl is enabled in your installation you can simply set [SYS][curlUse] in the Install Tool. The numbers around the 404 page content will disappear.

Jan On 28 March 2017 at 15:01

In short: change the following line in the FE section of your LocalConfiguration.php:

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

to

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

**Mathias Schreiber** · Accepted Answer · 2017-01-02T10:58:57+00:00

I added the full description from the install tool and I guess we might find the solution there.

How TYPO3 should handle requests for non-existing/accessible pages.

empty (default)

The next visible page upwards in the page tree is shown.
'true' or '1'

An error message is shown.
String

Static HTML file to show (reads content and outputs with correct headers), e.g. notfound.html or http://www.example.org/errors/notfound.html.
Prefix "REDIRECT:"

If prefixed with "REDIRECT:" it will redirect to the URL/script after the prefix.
Prefix "READFILE:"

If prefixed with "READFILE" then it will expect the remaining string to be a HTML file which will be read and outputted directly after having the marker "###CURRENT_URL###" substituted with REQUEST_URI and ###REASON### with reason text, for example: READFILE:fileadmin/notfound.html.
Prefix "USER_FUNCTION:"

If prefixed with "USER_FUNCTION:" a user function is called, e.g. USER_FUNCTION:fileadmin/class.user_notfound.php:user_notFound->pageNotFound where the file must contain a class user_notFound with a method pageNotFound() inside with two parameters $param and $ref.

What you configured:

You're passing a string, thus TYPO3 expects to find a file - which you don't have, because it's more like an URL.

From what you try to achieve I'd go with REDIRECT:/page-not-found/.

Thanks for pointing this one out btw, I will remove the string configuration from the core since it does not make sense to have more people trip into this pitfall.

TechQA.

TYPO3 7.6: 404 error page: HTML wrapped in numbers

There are 3 answers

How TYPO3 should handle requests for non-existing/accessible pages.

What you configured:

Cause

Workaround/solution

Related Questions in TYPO3

Related Questions in TYPO3-7.6.X

Popular Questions

Popular Tags

Trending Questions