[TYPO3-core] Reminder: : pageNotFound_handling HTTP status fix

Ernesto Baschny [cron IT] ernst at cron-it.de
Tue Jun 13 10:16:39 CEST 2006


Hi,

This has been discussed about a month ago, I think its not in CVS yet:

Martin Kutschker schrieb am 02.06.2006 16:25:

>> This is a reminder about CVS patch request
>>
>> Branch: HEAD, TYPO3_4-0
>>
>> Problem: if $TYPO3_CONF_VARS['FE']['pageNotFound_handling'] is set to
>> absolute or relative URL, than
>> $TYPO3_CONF_VARS['FE']['pageNotFound_handling_statheader'] is ignored
>> and client is redirected to error page using code 302. This is
>> especially bad for search engines like Google because (1) they may not
>> remove such pages from their index (2) sitemaps do not work properly.
>>
>> Solution: use t3lib_div::getURL() to fetch error page internally and
>> pass it to client with correct header. getURL() is extended to accept
>> custom HTTP headers that we need to send to 404 page (referrer and user
>> agent).
>>
>> Patch was discussed earlier in this list, I need one more +1 for it.

The patch by Dmitry and enhanced/changed by Martin Kutschker is almost
fine for me. I just tested it, and could simulate the problem that is
then fixed as proposed with the patch. I like that we just display the
error page (404) without redirecting (302) to yet another page. The user
is kept in the right context (URL-wise).

But I have a problem if I used to redirect to an error page on another
domain and it contains relative links/references. Things like

<img src="images/error.gif" />

will get broken if you don't redirect to the page, but show the content
in your current TYPO3 environment. You get broken images/links. A
potential solution would be to try to add a <base href="URL" /> to the
header of the outputted HTML code. The browser will then take care of
fetching the correct images/links (and this is what base href is for).

This should be skipped if there is already a "base href" on the error-page.

An (easier) solution would be to document that behaviour so that the
errorPage-creator has to make sure there are no relative links in the
errorPage and make the new behaviour only if a certain configuration
switch is enabled so that the old behaviour (302 redirect) is kept on
upgrades (backwards compatibility).

Maybe Dmitry or Martin can work something out with this new information? :)

Cheers,
Ernesto



More information about the TYPO3-team-core mailing list