#1 — PageCacheManager hits ignored by browser
| State | Resolved |
|---|---|
| Version: |
—
|
| Area | Functionality |
| Issue type | Bug |
| Severity | Important |
| Submitted by | Wichert Akkerman |
| Submitted on | Jan 25, 2006 |
| Responsible | Geoff Davis |
| Target release: |
—
|
Last modified on
Jan 08, 2009
by
Matthew Wilkes
If I do a get from a browser on a PageCacheManager cached page which is not in the browser cache the resulting HTTP response is ignored by browers (tested with FF and IE). If the browser has a cached copy a correct 304 response is generated which is handled correctly.
This is an example of a non-working response:
GET /wiggy/about/uyhki-kj/document_view HTTP/1.1
Host: panda:7070
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Firefox/1.0.4 (Ubuntu package 1.0.7)
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.7,it;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: myleaflang=empty; firstleafpage="1"; __ac="snip snip"
HTTP/1.x 200 OK
Server: Zope/(Zope 2.7.8-final, python 2.3.5, win32) ZServer/1.1 Plone/Unknown
Date: Wed, 25 Jan 2006 15:28:41 GMT
X-Pagecache: HIT
Content-Length: 73276
Content-Language: en
Content-Encoding: gzip
X-Cache-Headers-Set-By: CachingPolicyManager: /wiggy/caching_policy_manager
Expires: Wed, 25 Jan 2006 15:27:48 GMT
Vary: Accept-Encoding
Etag: admin|1137600256.45|316167
Cache-Control: max-age=0, s-maxage=86400, private, must-revalidate, pre-check=300, post-check=3600
Content-Type: text/html;charset=utf-8
- Steps to reproduce:
- Setup CMFCore 1.5.5, CacheFu svn trunk, default caching policies, disable caching in FF and reload a page.
Added by(anonymous)onJan 25, 2006 03:42 PM
From IRC:
Responsible manager:
geoff
→
(UNASSIGNED)
geoffd wiggy: not sure i understand your bug report - what do you mean when you say that the response is ignored?
wiggy geoffd: exactly that - the browser acts like the request never happened
wiggy geoffd: no error messages, continues to show the previous page
I am guessing that the problem is gzip-related. Note the Content-Encoding: gzip header.
I got this via email from Ricardo Newberry awhile back -- not sure if this is the Right Way to fix things, though. Need to investigate further.
Still experimenting with gzip and caching. Noticed that the
PageCacheManager product doesn't play well with gzip. I added the
following quickie fix.
PacheCache.py
replace line: 315...
ob.REQUEST.RESPONSE.setHeader(k, v)
with...
for k, v in headers.items():
if k.lower() == 'content-encoding':
ob.REQUEST.RESPONSE.enableHTTPCompression(REQUEST=ob.REQUEST)
else:
ob.REQUEST.RESPONSE.setHeader(k, v)
This works for my use case. More generically, I guess I should
change it to call the skin python script "enableHTTPCompression.py"
but I would still need to delete the 'content-encoding' header in any
case. Or maybe I should just delete this header during the
ZCache_set step instead.
Ric
Added byWichert AkkermanonJan 25, 2006 03:51 PM
That was a spot-on analysis and something both Live HTTP headers and fiddler did not reveal. The patch also fixed this for me.
Added byGeoff DavisonFeb 04, 2006 11:16 PM
I have checked in a fix to SVN. The problem was that the cache was storing a reference to the response headers rather than a copy of them. After caching, the response object compresses its data and alters the headers. The alterations ended up in the cache because of the reference. The next time the data is pulled from the cache, the headers no longer match the content. Fixed now, plus I have patched the source to preserve the compression flag in the response.
Responsible manager:
(UNASSIGNED)
→
geoff
Added byGeoff DavisonFeb 04, 2006 11:17 PM
Issue state:
unconfirmed
→
open
Added byGeoff DavisonFeb 04, 2006 11:18 PM
Wiggy, can you please confirm that the fix I checked in works?
Issue state:
open
→
in-progress
Added byGeoff DavisonMar 15, 2006 12:10 PM
Issue state:
in-progress
→
resolved
No responses can be added.
If you can, please log in before submitting a reaction.