[MAGNOLIA-1409] Stale cache on If-Modified-Since unless unconditional GET request Created: 27/Feb/07 Updated: 23/Jan/13 Resolved: 11/Jul/08 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | cache |
| Affects Version/s: | 3.0.1 |
| Fix Version/s: | 3.6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Henryk Paluch | Assignee: | Philipp Bärfuss |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Win32, jdk1.5.0_06, magnolia-3.0.1-bundle.tar.gz, MSIE 6.0.2800.1106,Firefox 1.5.0.10 |
||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
| Date of First Response: |
| Description |
|
After successfull publishing cycle (e.g. Activate -> Inbox Proceed) the /magnoliaPublic/ When anyone does uncoditional request (for example Shift-Reload in Firefox) then cache is successfully updated and all request are working properly (unless page is changed again). How to reproduce:
GET /magnoliaPublic/features.html HTTP/1.1 But it receives incorrect response: HTTP/1.1 304 Not Modified
It seems that cache is returning stale 304 response as long as someone unconditionaly requests that page (without If-Modified-Since) |
| Comments |
| Comment by Magnolia International [ 10/Jun/08 ] |
|
will try to check this for 3.6 |
| Comment by Philipp Bracher [ 11/Jul/08 ] |
|
It looks that the problem is the additional (length=4631) in the header. So the getDateHeader() method will fail. But if the cache is flushed the If-Modified-Since should be ignored. Needs tasting with 3.6 turnk |
| Comment by Philipp Bracher [ 11/Jul/08 ] |
|
The additional length 'provided' by IE does not cause any problem (the date is determined correctly). So I can't reproduce the issue with latest trunk (tested with IE7) |
| Comment by Magnolia International [ 12/Jul/08 ] |
|
so we could actually mark this as "fixed for 3.6" thanks to the revised cache |