Story #63815: Reduce communication between server and client
HTTP GET 'If-Modified-Since' ignored
RFC 1945 (HTTP protocol) in section 8.1 says:
The semantics of the GET method changes to a "conditional GET" if the
request message includes an If-Modified-Since header field. A
conditional GET method requests that the identified resource be
transferred only if it has been modified since the date given by the
If-Modified-Since header, as described in Section 10.9.
/typo3/sysext/cms/tslib/class.tslib_fe.php has function sendCacheHeaders(), that is working before content output. Good place to implement conditional GET.
I suggest to put logic for If-Modified-Since in section, that works if page is cached, and operate on $this->register['SYS_LASTCHANGED'].
Such way, if page has USER_INT object (plugins and so on), we will not disappoint HTTP client.
(issue imported from #M5147)
#1 Updated by Popy no-lastname-given over 12 years ago
Try this extension : http://typo3.org/extensions/repository/view/pp_optimizer/1.0.0/
It have been made to correct this bug :)
#5 Updated by Popy no-lastname-given over 12 years ago
@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 !
#6 Updated by Olaf Bottek over 11 years ago
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.
#9 Updated by Dmitry Dulepov over 11 years ago
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.
#10 Updated by Popy no-lastname-given over 11 years ago
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)
#11 Updated by Olaf Bottek over 11 years ago
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?