Bug #63821
Story #63815: Reduce communication between server and client
HTTP header status 200 should be 304 when cached page not modified
| Status: | New | Start date: | 2014-12-13 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assigned To: | - | % Done: | 0% |
|
| Category: | - | Spent time: | - | |
| Target version: | - | |||
| TYPO3 Version: | 7 | Is Regression: | No | |
| PHP Version: | 5.5 | Sprint Focus: | ||
| Complexity: | medium |
Description
When a cached page is requested, a "Last-Modified" header is sent with the response, based on the SYS_LASTCHANGED field of the page.
The server response always has a "HTTP/1.1 200 OK" status
There is no check if the browser request comes with a "If-Modified-Since" header. If so, It should be compared with SYS_LASTCHANGED. If the date of SYS_LASTCHANGED is earlier or equal than "If-Modified-Since", it should return a "HTTP/1.1 304 Not Modified" status, instead of "HTTP/1.1 200 OK".
A "HTTP/1.1 304 Not Modified" status does not have to send the content of the page, which reduces traffic.
Related issues
History
#1 Updated by Patrick Broens 8 months ago
- Parent task set to #63815
#2 Updated by Patrick Broens 8 months ago
- TYPO3 Version changed from 6.2 to 7
#3 Updated by Sigfried Arnold 8 months ago
In principle, this is a good idea - but it is a bad idea to bind this at SYS_LASTCHANGED since this value does not necessarily contain the needed information
for example, if the page contains a plugin which generates a "random" output, you can't send 304 by comparing with SYS_LASTCHANGED - and TYPO3 simply does not know if an INT-cObject has not changed since the last request.
The only soltion for that would be a really careful cache configuration (by the Developer using the right cObject and the Editor, by defining those values in the cache control settings) - but this is also not trivial, since taking a page from the TYPO3 cache does not necessarily mean, it has not been modified.