Uploaded image for project: 'JIRA (including JIRA Core)'
  1. JIRA (including JIRA Core)
  2. JRA-16021

Form data lost when using back button on HTTPS site

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: 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.

        Attachments

          Issue Links

            Activity

            Hide
            blane 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
            blane 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@atlassian.com 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@atlassian.com 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@atlassian.com Matt Ryall 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@atlassian.com Matt Ryall 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:
                blane Brian Lane
              • Votes:
                8 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated: