HTTP 302 redirect caching
-
lamplightdev last edited by
Hello,
I'm developing a site where I am using the common Post/Redirect/Get pattern (https://en.wikipedia.org/wiki/Post/Redirect/Get) when submitting forms. In my particular case this is items for a todo list - so I'm POSTing to say https://site.com/group, processing that request server side adding the new item to a database, and then returning a 302 response (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3) to indicate the browser should redirect (GET) to https://site.com/group which then displays a list of all the todos submitted to the db. This works on Opera Mini, but on both Opera Mini on Android (v12) and on the microemulator on Mac OSX (I haven't tested on other versions), the resulting page shows the list of todos without the new item, until I refresh the page manually at which point the list returned does include the new item.
I'm assuming what's happening here is that the page being shown after the redirect is the version which has been cached on Opera's proxy server previous to the POST request. If this is the case, is there a way I can indicate to the proxy server that it should display a fresh version of the page from my server rather than the cached version? I have also tried the more correct 303 status code (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.4) but the same thing happens - although the spec says for this:
'The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable'
although I have found no references to how this redirected request can me marked as non-cacheable. Incidentally all other browsers seem not to cache this redirected request at all.
Thanks very much for you help in advance.
Chris.
-
smyru last edited by
It's probably not a problem with caching any redirect but rather caching the original GET to the site.com/group. You might try setting some cache control headers on this very resource to enforce revalidation in the server browser or use some bogus random query to treak the server into thinking, it's dealing with different URL.
You could as well look into using operamini.page.maxAge attribute with JS. Not sure whether this feats well your design.
-
lamplightdev last edited by
Thanks Smyru - I will have a look at operamini.page.maxAge as I think that might fix it.