Ticket #11970 (confirmed Bug)

Opened 5 years ago

Last modified 3 years ago

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:1 Changed 5 years ago by saurabhmehndiratta

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)]

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:4 Changed 5 years ago by MatthewWilkes

  • Description modified (diff)

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:6 Changed 4 years ago by kleist

see also #12447

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:

 https://github.com/plone/Products.CMFPlone/blob/master/Products/CMFPlone/skins/plone_form_scripts/content_status_modify.cpy#L68

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.

Note: See TracTickets for help on using tickets.