Ticket #11970 (confirmed Bug)
content_status_modify calls are cached in Firefox 5
Reported by: | saurabhmehndiratta | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 4.x |
Component: | General | Version: | 4.1 |
Keywords: | Cc: |
Description (last modified by MatthewWilkes) (diff)
The workflow status update using content actions dropdown seems to be working inconsistently in Firefox5.
tl;dr: Firefox handles the request with its in-browser cache causing some subsequent transitions to be ignored.
Content actions have few options for workflow status, for example (HTML markup looks like):
<li> <a title="Declining the item back will return the item to waiting for authoring stage. You should preferably include a reason for why it was declined." id="workflow-transition-decline" class="kssIgnore" href="http://SERVER/OBJECT_PATH/content_status_modify?workflow_action=decline"> <span class="subMenuTitle">Decline</span> </a> </li>
When workflow status update request is sent for the first time (i.e. " http://SERVER/OBJECT_PATH/content_status_modify?workflow_action=decline"), the script content_status_modify.cpy gets executed and depending on the status it gets redirected to " http://SERVER/OBJECT_PATH/folder_contents". This redirection has been configured through content_status_modify.cpy.metadata, by specifying "action.success=redirect_to:request/orig_template|string:folder_contents" Now the issue is that Firefox5 caches the HTTP 302 response and strictly obeys it. Thus, when the same request is being sent (i.e. " http://SERVER/OBJECT_PATH/content_status_modify?workflow_action=decline") then the script content_status_modify.cpy is not getting executed at all (browser redirects to folder_contents view directly). Application Server Logs (Apache is used in our case) clearly says that no request has been made for content_status_modify.
Firefox 5 directly redirects to " http://SERVER/OBJECT_PATH/folder_contents". Firefox5 "Cache Service" stores 302 response and can be verified by entering "about:cache?device=disk" in browser URL.
-------------------------------------------------------------------------------------------- Cache entry information key: http://SERVER/OBJECT_PATH/content_status_modify?workflow_action=decline fetch count: 10 last fetched: 2011-06-30 16:14:14 last modified: 2011-06-30 12:54:06 expires: 1970-01-01 05:30:00 Data size: 0 file on disk: C:\Users\localUser\AppData\Local\Mozilla\Firefox\Profiles\fu8m0a7g.default\Cache\D\71\F3527d01 Security: This document does not have any security info associated with it. Client: HTTP request-method: GET request-Accept-Encoding: gzip, deflate response-head: HTTP/1.1 302 Moved Temporarily Date: Thu, 30 Jun 2011 07:23:34 GMT Server: Zope/(unreleased version, python 2.4.6, linux2) ZServer/1.1 Plone/3.3.5 Content-Type: text/plain; charset=utf-8 Location: http://SERVER/OBJECT_PATH/folder_contents Cache-Control: max-age=315360000 Expires: Sun, 27 Jun 2021 07:23:34 GMT Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 121 --------------------------------------------------------------------------------------------
The same cache entry can be seen in other browsers also, but it seems that they do not follow 302 cache strictly and thus for every request content_status_modify.cpy gets exectued fine in other browsers.
Change History
comment:2 Changed 5 years ago by MatthewWilkes
- Priority changed from major to critical
- Summary changed from Workflow update script (content_status_modify.cpy) working inconsistently in Firefox 5 to content_status_modify calls are cached in Firefox 5
- Component changed from Unknown to Infrastructure
- Description modified (diff)
- Milestone set to 4.x
Been a bit clearer about the problem
comment:3 Changed 5 years ago by MatthewWilkes
Can you please confirm if this is fixed already in Plone 4?
comment:5 Changed 5 years ago by saurabhmehndiratta
Hi,
One of the solutions to this problem would be (i have applied it in Plone 3.3.5):
Add the following line to the script content_status_modify.cpy
context.REQUEST.RESPONSE.setHeader('Cache-control','must-revalidate,max-age=0,no-cache')
By doing so we are restricting browser not to use the cached version. When the HTTP request to content_status_modify is being sent for the first time (and also for all subsequent requests), then this line changes the Header of the HTTP Response by adding the following entry:
Cache-Control: must-revalidate,max-age=0,no-cache
This entry tells the browser not to use the cached version of that Request-Response pair, but to make a fresh request again.
Tested under : Firefox 5 (in Windows and Mac)
Other observation: For buttons like Copy, Delete, Paste .... Plone uses folder_copy.cpy, folder_delete.cpy or object_delete.cpy,etc. All these scripts are also configured using .metadata files, and redirect_to is used to redirect to another view/URL.
But, since clicking a button is a part of form-actions thus (unlike anchor <a> clicks request-response pair) browsers do not seem to be caching button clicks request-response pair.
comment:7 Changed 4 years ago by kleist
- Status changed from new to confirmed
- Version set to 4.1
- Component changed from Infrastructure to General
comment:8 Changed 4 years ago by kleist
Still an issue with later versions of Firefox?
If so, this might be the place to add the suggested code:
comment:9 Changed 4 years ago by kleist
How can this be "critical", when still open since fourteen months?
or, rephrased:
How can this still be open since fourteen months, when "critical"?
comment:10 Changed 3 years ago by kleist
- Priority changed from critical to major
Demoting from "critical" to "major". Maybe we could even close it? I mean, Firefox 5 was a while ago, and nobody has confirmed that this is still an issue with current versions.
More information:
Plone 3.3.5 Zope (unreleased version, python 2.4.6, linux2) Python 2.4.6 (#1, Apr 15 2010, 11:24:49) [GCC 4.1.2 20080704 (Red Hat 4.1.2-46)]