JIRA
  1. JIRA
  2. JRA-16021

Form data lost when using back button on HTTPS site

    Details

    • Type: Bug Bug
    • Status: Open (View Workflow)
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Web interface
    • Labels:

      Description

      The Cache-Control settings for JIRA prevent the back button working on sites using HTTPS (like this one):

      Cache-Control: no-cache, no-store, must-revalidate
      

      The proper cache settings to use are the ones used by Confluence for the same purpose:

      Cache-Control: no-cache, must-revalidate
      

      See Chris Owen's blog post on this topic from 2007 for more information.

        Issue Links

          Activity

          Hide
          Brian Lane added a comment -

          For reference we have Chris's internal blog about changes here - and I also found this blog that describes some of the issues as well.

          http://blog.pluron.com/2008/07/why-you-should.html

          Show
          Brian Lane added a comment - For reference we have Chris's internal blog about changes here - and I also found this blog that describes some of the issues as well. http://blog.pluron.com/2008/07/why-you-should.html
          Hide
          Anton Mazkovoi [Atlassian] added a comment - - edited

          One thing to note if we decide to go with removing "no-store" from the caching headers is that this could be a problem if there is JavaScript on the page that ran and modified the DOM of the page.

          As far as I can tell based on what I have been hearing from different people (handling different bugs and support cases), when returning back to the page (pressing the browser back button) some browsers show the last version of the DOM, i.e. the DOM that was the result of JavaScript running and modifying the original HTML. Other browsers show the original HTML. The trouble is that depending of what JavaScript did, we may want one behaviour or the other.

          For example, if the JavaScript disbaled a button on the page to prevent double submit, and the browser shows the last version of the DOM, the button will be disabled and cannot be pressed again. Which is not what we want. If the JavaScript moved an element from one place to another (e.g. drag-n-drop was performed) and original HTML is shown instread, this is not what we want either.

          I believe we do not have control on page per page basis of what the browser should do.

          We need to investigate the above problems (well, first prove their existence) before we make these changes.

          But at the moment it seems like removing "no-store" will have edge cases that we cannot fix.

          Show
          Anton Mazkovoi [Atlassian] added a comment - - edited One thing to note if we decide to go with removing "no-store" from the caching headers is that this could be a problem if there is JavaScript on the page that ran and modified the DOM of the page. As far as I can tell based on what I have been hearing from different people (handling different bugs and support cases), when returning back to the page (pressing the browser back button) some browsers show the last version of the DOM, i.e. the DOM that was the result of JavaScript running and modifying the original HTML. Other browsers show the original HTML. The trouble is that depending of what JavaScript did, we may want one behaviour or the other. For example, if the JavaScript disbaled a button on the page to prevent double submit, and the browser shows the last version of the DOM, the button will be disabled and cannot be pressed again. Which is not what we want. If the JavaScript moved an element from one place to another (e.g. drag-n-drop was performed) and original HTML is shown instread, this is not what we want either. I believe we do not have control on page per page basis of what the browser should do. We need to investigate the above problems (well, first prove their existence) before we make these changes. But at the moment it seems like removing "no-store" will have edge cases that we cannot fix.
          Hide
          Matt Ryall [Atlassian] added a comment -

          The back button is not working properly on HTTPS on JAC at the moment, and I just lost yet another comment. I think this should be recategorised as a bug, because it's the same problem as JRA-14031.

          We've been running Confluence with 'Cache-Control: no-cache, must-revalidate' for several years now with no negative effects. In our experience, the problem Anton is talking about hasn't been a problem at all. The main reason you want need the back button to work is so that you can get back to your data when the server goes down or doesn't respond.

          Show
          Matt Ryall [Atlassian] added a comment - The back button is not working properly on HTTPS on JAC at the moment, and I just lost yet another comment. I think this should be recategorised as a bug, because it's the same problem as JRA-14031 . We've been running Confluence with 'Cache-Control: no-cache, must-revalidate' for several years now with no negative effects. In our experience, the problem Anton is talking about hasn't been a problem at all. The main reason you want need the back button to work is so that you can get back to your data when the server goes down or doesn't respond.

            People

            • Assignee:
              Unassigned
              Reporter:
              Brian Lane
            • Votes:
              8 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated: