Project

General

Profile

Actions

Bug #17457

closed

External URL leads to Internal Server Error (Error 500)

Added by Oliver Kuka over 17 years ago. Updated over 14 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Communication
Target version:
-
Start date:
2007-07-11
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.1
PHP Version:
4.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

We have a mysterious problem with the pagetype "External URL". Instead of leading to the URL, an Internal Server Error (on the typo3 page) appears, regardless if you click the link in the navigation, use the direkt URL to the page with the external URL or even just use "?jumpurl=http://page.url/". It doesn't matter what kind of protocoll the URL has or if it just leads to a file on the server.

Now, to make things really strange, there's one occasion that makes the external URL work. That is, if one is logged in into the backend and can see the page and all above it (has the "show page" right). The jumpurl parameter works as well, as long, as an id parameter is given, that the logged in user can see (?id=cansee&jumpurl=page). Of course all must happen in the same browser(session).

The error.log just states "Premature end of script headers: /path/to/htdocs/index.php".

I assume there's a difference how those pages are handled when logged in and not logged in. But what? And why does it concern the pagetype external URL and none else?

This error just appeared. We didn't change anything on the typo3 installation. And the server admin claims to be innocent as well. When it appeared we had typo3 4.0 and we just updated it to 4.1.1, hoping that it would fix the problem (which it didn't).

I hope anyone can give some hint or even a solution to this problem. Thanks in advance.

PHP 4.3.4
Apache 1.3.29
(issue imported from #M5944)

Actions #1

Updated by Oliver Kuka over 17 years ago

Ah, forgot to mention. We're not using RealURL (in case it gets confused with those problems).

Actions #2

Updated by Oliver Hader over 17 years ago

Hm, this could possibly be faulty .htaccess file or a faulty configuration of your Apache webserver (maybe introduced by upgrading Apache?).
Can you tell the URL where this happens? Maybe (parts of) HTTP headers tell something...

Actions #3

Updated by Oliver Kuka over 17 years ago

The .htaccess was one of the first things I tried by renaming the file. Brought the same errors.
The Apache configuration hasn't been touched, as far as I know and while there was an upgrade, it was just some minor bugfix with SuSE Update. I can try to get more information from the server admins, but it seems that they are... well, just doing their job by the book.. don't expect too much there.

A page where the error occurs would be: http://www.ph-ludwigsburg.de/3000
(You can try out without triggering mod_rewrite or using jumpurl and get the same results, unless you have a backend login with the proper rights.)

I'm grateful for any hint :) .

Actions #4

Updated by Oliver Hader over 17 years ago

Really strange. When I used the link you told ".../3000", I got the error. After some reloads and tests I suddenly could see the "Technik" page, but with no regular content - of course it should be an external link.
If I use the ".../3000.html" as link I get the server error again. So, did you install any extensions to TYPO3 or any other modules to your server that affects caching, header-rewriting, static-file-saving/-caching or whatever?

Actions #5

Updated by Oliver Kuka over 17 years ago

Sorry for the delay with the reply.
The reloads sound interesting. Never tried to spam reload. A co-worker told me, he got it to work once as well. Makes it even stranger.

What kind of page did you see? A site with the same basic layout as the main page (just different colors maybe) or something completely different, a page that was made with simple HTML files?

Regarding the extension, we're not running something special. I tried deactivating some extensions, but still got the same results. And we didn't change anything till it suddenly stopped working. Making the page non-cacheable doesn't affect it as well.

What still bugs me is the difference that occurs when a user with the correct permissions in the backend is logged in. What difference does it make for the headers? Additional cookies are used, I can see that. But aside that?

Actions #6

Updated by Ralf Merz over 16 years ago

Hi,

I have the same error on PHP 4.4.8 and TYPO3 4.1.6.
I hope someone can help me. This issue is one year old now. What I know is, that the apache webserver has been restarted yesterday. Today, I suddenly have the same problem:
A page of type "external URL" throws an error 500.
But if I´m logged in the backend, it works. Do you think it´s a TYPO3 error or the restart of the apache went wrong?
Thank´s for any hints.

Greets

Actions #7

Updated by Oliver Hader over 16 years ago

On digging into Ralf's problem, the reason of that was a too big log file, created by the awstats extension (from TER, not a Linux package). Thus, the system was not able to add more data to that file since the maximum allowed size a file system supported was exceeded.

Actions #8

Updated by Chris topher over 14 years ago

OK, so this was an error with awstats (or other extensions writing logfiles) and should be fixed there. There could e.g. be an option to delete old entries from logfiles when updating the statistics, maybe via Cronjob. ics_awstats for example has such an option.

Actions

Also available in: Atom PDF