TYPO3 Core

Hi Christoph,

what do you mean with "File List-Extension Projects"?

Hi Markus,

I referred to the TYPO3 CMS community extensions http://forge.typo3.org/projects/extension-dr_blob and http://forge.typo3.org/projects/extension-file_list that are listed both as "File List" in the dropdown on the left hand side.

As I was not sure if this bug is related to one of this extensions I set the project to "core".

I have none of these extensions installed. The bug is about the default extension filelist included in the TYPO3 default package respectively the related(?) content element "Special Elements > File Links".

I am just not sure where to place this bug report, so I chose "Core".

Great :)

I am using TYPO3 version 6.2.3. The filelist and css_styled_content version is therefore 6.2.0.
In the template, I've included the css_styled_content-object without version annotation. So I expect that to be the latest version.

• realurl (version 1.12.8) (only for pages (not for files) - filelinks point directly to the file on the filesystem)
• naw_securedl (version 1.8.1) not active for the files that are linked by this content element

For the buggy filelist I chose "Layout 3" an display the filesize in the frontend.

Yesterday, I tried to reproduce this error on a different page using the same configuration but everything worked fine.

Today, using the "buggy" page, it fails again, using Firefox 30.0. I'm currently logged in into the backend.

Now comes the odd part:
Using Firebug, I tried to analyse the network traffic: Status: aborted - same Error as yesterday. But sometimes, Firebug shows me some transferred traffic before the connection closes. Also, the initial loading after removing the heading took much longer than the other requests. So I think, the page is rendered by TYPO3 and the transfer afterwards fails.
I switched to Internet Explorer (bad, I know) and used F12 for analysing the traffic, hoping I get some more information. But in IE, everything works fine (not logged into backend).
When I log into backend in IE, loading this page also fails (F12: aborted).

Loading the page also works, if I start Firefox in private-mode (to get an independent session) without being logged in into the backend. Here, the page loads correctly, showing all downloads and correctly displaying no header for the content element (which seems to be somehow related to this error).

It seems like the issue is related to the backend session.

This TYPO3 installation runs on a rented (shared) webspace at Strato. I don't think somewhat is killing the Apache process (otherwise there might have been complaints from Strato). Loading this page also does not exceed the max_execution_time limit.

As far as I know, you can define header("connection: close"); to abort to connection to the server.

Ok, I'm sorry, this is impossible for me to reproduce, since I was logged in to the BE when I tested this.
The header you mentioned does NOT abort the connection, it tells the browser that it must not reuse this connection for another request to the server. (HTTP/1.1)
There's no way to abort a connection directly from PHP AFAIK.

Ok.

I understand that this is quite hard to reproduce. Until now, even I didn't manage to force this error on a different page of this setup.

Is there anything I can do to get you further information that are useful for debugging?

Unfortunately, no. You can only debug on your own, on that specific page.
I can help you, if you need a hint where to start.

A hint where to start would be great, thanks.

Yesterday, I discovered this issue at various other content elements too: text and text and image on different pages (same TYPO3 instance).
Before the errors occurred, I removed a plugin and afterwards cleared all caches using the install tool. On the concerned pages, I fixed the by issue changing a little in the content element (opening and saving this element didn't help, although during this process the page cache is reset as well).

I also remembered using the plugin cf_lifetime_patch (Version 1.2.1 - compatible with TYPO3 6.x) which could be involved in this problem. What do you think?

This issue still occurs in both browsers an was not related to backend-sessions this time.

This TYPO3 setup is using multiple domains an manages independent website (using different TypoScript-Configs). Yesterday, the problem occurred on two different websites, also different from the one where I first discovered the problem.

I don't know cf_lifetime_patch and what it actually does.

You can set a breakpoint in the file typo3/sysext/frontend/Classes/ContentObject/FilesContentObject.php::render() and debug step by step until you bail out with your error.

Ok,

thank you for your help, Markus!

Greetings
Christoph