Feature #17085
closedStory #63815: Reduce communication between server and client
HTTP GET 'If-Modified-Since' ignored
Added by Dmitriy Larionov over 17 years ago. Updated over 8 years ago.
0%
Description
RFC 1945 (HTTP protocol) in section 8.1 says:
--skip--
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.
--skip--
/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)
Files
typo3_src-4.1.http-If-Modified-Since.patch (422 Bytes) typo3_src-4.1.http-If-Modified-Since.patch | Administrator Admin, 2007-03-06 20:05 | ||
class.tslib_fe.php.diff (2.54 KB) class.tslib_fe.php.diff | Administrator Admin, 2007-03-13 11:14 |
Updated by Popy no-lastname-given over 17 years ago
Try this extension : http://typo3.org/extensions/repository/view/pp_optimizer/1.0.0/
It have been made to correct this bug :)
Updated by Oliver Hader over 17 years ago
Popy, could you please attach a patch against the Core to have the feature in the TYPO3 Core as well? Thanks in advance!
Updated by Popy no-lastname-given over 17 years ago
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.
Updated by Dmitriy Larionov over 17 years ago
Hey!
My patch for 4.1 is attached to bug record.
Updated by Popy no-lastname-given over 17 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 !
Updated by Olaf Bottek over 16 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.
Updated by Popy no-lastname-given over 16 years ago
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.
Updated by Popy no-lastname-given over 16 years ago
Done.
Only one line was missing : "&& !$this->doWorkspacePreview()" in the if statement (sendCacheHeaders function)
Updated by Dmitry Dulepov over 16 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.
Updated by Popy no-lastname-given over 16 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)
Updated by Olaf Bottek over 16 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?
Updated by Alexander Willner over 15 years ago
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).
Updated by Frederic Gaus almost 14 years ago
Google writes in its technical guidlines (webmaster-tools)
- Make sure that your Webserver supports the HTTP-Header "If-Modified-Since"
Updated by Xavier Perseguers about 13 years ago
- Category deleted (
Communication) - Target version changed from 4.6.0 to 4.6.0-beta1
Updated by Xavier Perseguers about 13 years ago
- Target version deleted (
4.6.0-beta1)
Updated by Stephan Großberndt over 10 years ago
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.
Updated by Gerrit Code Review over 10 years ago
- Status changed from New to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/27109
Updated by Simon Schaufelberger over 10 years ago
just pushed the patch file to gerrit that something is going on here!
please excuse the bad commit message!
Updated by Gerrit Code Review over 10 years ago
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
Updated by Gerrit Code Review over 10 years ago
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
Updated by Gerrit Code Review over 10 years ago
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
Updated by Mathias Schreiber over 8 years ago
- Status changed from Under Review to Closed
will continue in #63821