Feature #17085

Story #63815: Reduce communication between server and client

HTTP GET 'If-Modified-Since' ignored

Added by Dmitriy Larionov over 12 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2007-03-06
Due date:
% Done:

0%

PHP Version:
4.3
Tags:
Complexity:
Sprint Focus:

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)

typo3_src-4.1.http-If-Modified-Since.patch View (422 Bytes) Administrator Admin, 2007-03-06 20:05

class.tslib_fe.php.diff View (2.54 KB) Administrator Admin, 2007-03-13 11:14


Related issues

Related to TYPO3 Core - Epic #55065: WP: Overall System Performance (Backend and Frontend) Closed 2010-07-02 2014-07-09
Duplicated by TYPO3 Core - Bug #63821: HTTP header status 200 should be 304 when cached page not modified New 2014-12-13

History

#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 :)

#2 Updated by Oliver Hader over 12 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!

#3 Updated by Popy no-lastname-given over 12 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.

#4 Updated by Dmitriy Larionov over 12 years ago

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

#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.

#7 Updated by Popy no-lastname-given over 11 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.

#8 Updated by Popy no-lastname-given over 11 years ago

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

#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?

#12 Updated by Alexander Willner over 10 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).

#13 Updated by Frederic Gaus almost 9 years ago

Google writes in its technical guidlines (webmaster-tools)

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

#14 Updated by Xavier Perseguers about 8 years ago

  • Category deleted (Communication)
  • Target version changed from 4.6.0 to 4.6.0-beta1

#15 Updated by Xavier Perseguers about 8 years ago

  • Target version deleted (4.6.0-beta1)

#16 Updated by Simon Schaufelberger over 5 years ago

update?

#17 Updated by Stephan Großberndt over 5 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.

#18 Updated by Gerrit Code Review over 5 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

#19 Updated by Simon Schaufelberger over 5 years ago

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

please excuse the bad commit message!

#20 Updated by Gerrit Code Review over 5 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

#21 Updated by Gerrit Code Review over 5 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

#22 Updated by Gerrit Code Review over 5 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

#23 Updated by Alexander Opitz almost 5 years ago

  • Parent task set to #63815

#24 Updated by Mathias Schreiber almost 4 years ago

  • Status changed from Under Review to Closed

will continue in #63821

Also available in: Atom PDF