[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/
returns incorrect 304 Not Modified response on conditional GET request with If-Modified-Since - as does MSIE on Reload request.

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:

  • the content remains old, although Ethereal reveals that MSIE correctly does GET request with If-Modified-Since Clause:

GET /magnoliaPublic/features.html HTTP/1.1
...
If-Modified-Since: Tue, 27 Feb 2007 09:29:32 GMT; length=4631

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

Generated at Mon Feb 12 03:26:38 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.