TYPO3 Core

Try this extension : http://typo3.org/extensions/repository/view/pp_optimizer/1.0.0/

It have been made to correct this bug :)

Popy, could you please attach a patch against the Core to have the feature in the TYPO3 Core as well? Thanks in advance!

No problem, I'm on it :)

The extension contains a TSFE XCLASS, wich also looks like a patch, but I think i had rewritten the whole function.

Hey!
My patch for 4.1 is attached to bug record.

@see file class.tslib_fe.php.diff

This part will disable outputting if the content hasn't changed.

The bad point is : The method isOutputting isn't used before outputting $TSFE->beLoginLinkIPList(); and $BE_USER->extPrintFeAdminDialog();

Possible optimisation : is it really usefull to re-evaluate this method each time it is called (2 times for now) ? I think result should be cached (in a TSFE proprety maybe) after the first call of this method

Happy to help the community !

Hey, what is the status on this issue. Poppy, the extension seams to do nothing on Typo3 4.1.5.

When can we await this in Core?

Also Popy, what do the "bad point" things mean in result? So which functionality is disable through this patch? Maybe it is an idea to enable client caching conditional with an additional config.enableClientCaching next to config.sendCacheHeaders - or add another value to this one.

This should be implemented very soon, because this reduces the load on Typo3 installations dramatically.

No fonctionnality is disabled. And i said a stupid thing, because when $BE_USER->extPrintFeAdminDialog(); writes something, the caching is disabled, so there's no problem.

Right now I'm testing the extension on a 4.1.6 installation.

Done.
Only one line was missing : "&& !$this->doWorkspacePreview()" in the if statement (sendCacheHeaders function)

There is no much sense in fixing this. This HTTP header works fine for static files but PHP scripts are always executed, even with this header. This will not reduce load to TYPO3 much because TYPO3 still have to check if page was modified, which involves checking cache, etc. Almost same processing as when page is fetched normally. I did not see the implementation but it may also affect various statistics scripts that hook to TSFE to log visitors.

It does not affect anything in hooks or statistics.

There is two differences with the standard method :
1) The page is always requested (with the standard solution, the browser don't ask for the page, so no stats, and no check for modifications)
2) When the page is not modified, no data is sent ton the browser (even if the content is generated)

Dimitry, maybe my words "...reduces the load on Typo3 installations..." are not precisely enough. I mean that having the response standard is having a positive impact on systems running Typo3 in terms of load and others.

Okay I understand that it does not change that much in Typo3 itself, processing time wise, but still it is a difference if you finally sent out a 304 header with far below 1k of data or a cached page with a same size 200 header plus the content. This might be just a small difference, but count this is to the amount of request you have on websites... Furthermore this will also reduce the time a webserver thread needs to answer a request and also this adds up on more requests. In the end you can do more requests per second on the same installation. It also has an impact on the bandwidth, which might as well allow more requests per second. And just imagine the difference in the user experience if he already has the page cached. You can't even beat this with static files.

But there's also a different view to it. Typo3 is doing a lot of things to have an efficient caching process and it proved to work. Now the thing is that it fails on just this one piece - if someone on the client side is using it. I mean the information if the page has changed is there anyway and Typo3 is using it internally for the caching, so why not also return the correct header for it, if the client asks for it? Bye the way, this standard is supported and used by all major browsers and therefor millions of users and the search engine robots as well.

Of course side effects have to be solved if they are there, but it seams to me that it is not impossible to solve. Well every feature and functionality in Typo3 has been already changed, updated and refactored, why should this feature be left aside?

I totally agree with Olaf. Although the RFC 2616 only states that the server SHOULD respond with a 304 status code, I think its a much cleaner approach if Typo3 would send it (with all advantages Olaf identified).

Google writes in its technical guidlines (webmaster-tools)

- Make sure that your Webserver supports the HTTP-Header "If-Modified-Since"

update?

This should become at must have for TYPO3 6.2, with even backports to older versions.
In a wider range this belongs to the performance tasks.

just pushed the patch file to gerrit that something is going on here!

please excuse the bad commit message!

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/27109

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/27109

Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/27109