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

          Brian Lane created issue -
          Brian Lane made changes -
          Field Original Value New Value
          Link This issue is related to JRA-14031 [ JRA-14031 ]
          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
          Brian Lane made changes -
          Workflow jira [ 148367 ] Feature Request Workflow [ 162451 ]
          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.
          Anton Mazkovoi [Atlassian] made changes -
          Fix Version/s 4.1 [ 14244 ]
          Fix Version/s 4.0 [ 14091 ]
          Wojciech Seliga made changes -
          Assignee Wojciech Seliga [Atlassian] [ wseliga ]
          Wojciech Seliga made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Wojciech Seliga made changes -
          Status In Progress [ 3 ] Open [ 1 ]
          Wojciech Seliga made changes -
          Assignee Wojciech Seliga [Atlassian] [ wseliga ]
          Edwin Wong [Atlassian] made changes -
          Labels 4_1
          Edwin Wong [Atlassian] made changes -
          Fix Version/s 4.1 [ 14244 ]
          Chris Mountford [Atlassian] made changes -
          Priority Blocker [ 1 ] Major [ 3 ]
          Roy Krishna [Atlassian] made changes -
          Workflow Feature Request Workflow [ 162451 ] PM Feature Request Workflow [ 227871 ]
          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.
          Matt Ryall [Atlassian] made changes -
          Summary HTTPS cache header settings Form data lost when using back button on HTTPS site
          Description Conf 3 is doing some html changes to improve performance when being used with HTTPS.

          We should review these changes and look to add them to JIRA 4 as well.


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

          {noformat}
          Cache-Control: no-cache, no-store, must-revalidate
          {noformat}

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

          {noformat}
          Cache-Control: no-cache, must-revalidate
          {noformat}

          See [Chris Owen's blog post|http://blogs.atlassian.com/developer/2007/12/cachecontrol_nostore_considere.html] on this topic from 2007 for more information.
          Component/s Web interface [ 10126 ]
          Matt Ryall [Atlassian] made changes -
          Issue Type Improvement [ 4 ] Bug [ 1 ]
          Workflow PM Feature Request Workflow [ 227871 ] JIRA Bug Workflow w Kanban v5 [ 341452 ]
          Mark Lassau [Atlassian] made changes -
          Component/s Performance [ 10660 ]
          Oswaldo Hernandez [Atlassian] Bugmaster made changes -
          Workflow JIRA Bug Workflow w Kanban v5 [ 341452 ] JIRA Bug Workflow w Kanban v6 [ 661530 ]
          Oswaldo Hernandez [Atlassian] Bugmaster made changes -
          Workflow JIRA Bug Workflow w Kanban v5 [ 661530 ] JIRA Bug Workflow w Kanban v6 [ 672673 ]

            People

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

              Dates

              • Created:
                Updated: